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I.  INTRODUCTION 


A.  PURPOSE 

The  purpose  of  this  thesis  is  to  develop  formal  methodologies  and  software  to 
improve  the  naval  aviation  mishap  investigation  and  reporting  process  as  described  by  the 
OPNAV  3710  series  instruction.  The  use  of  information  technology  and  a  customized 
application  will,  it  is  hoped,  improve  the  quality,  timeliness  and  accuracy  of  an 
investigation  by  providing  logical  direction  and  reducing  administrative  overhead.  The 
focus  of  our  research  is  on  supporting  the  deliberation  process  occurring  during  the 
mishap  investigation  process.  This  thesis  will  outline  the  requirements  of  such  an 
application  and  provide  an  example  of  a  basic  prototype  of  the  key  element  of  the  system. 

B.  SCOPE 

The  scope  of  this  thesis  encompasses  the  development  of  a  Decision  Support 
System  that  supports  the  Naval  Aviation  Mishap  reporting  process,  concentrating  on  the 
development  and  implementation  of  a  "deliberation  model".  Object  oriented  and  Rapid 
Application  Development  technologies  bring  this  type  of  development  out  of  the 
professional  software  programming  environment  and  put  it  in  the  hands  of  "power-  users" 
and  non-  programmers.  It  is  our  intention  to  support  the  end-  user  computing 
environment:  We  describe  an  architecture  which  developers  can  easily  implement  and 
focus  on  the  "deliberation"  model  and  application  which  is  unique  research.  Rather  than 
focusing  on  the  implementation  of  a  prototype  only,  we  also  present  the  development  of 
the  underlying  model.  The  implementation  of  the  entire  system  is  a  topic  in  this  thesis, 
but  it's  importance  is  secondary.  Our  primary  goal  is  the  development,  formalization,  and 
implementation  of  the  mishap  investigation  deliberation  process,  and  we  present  a  basic 
implementation  within  an  architecture  for  a  complete  client/  server  system. 


1 


C.  MISHAP  CHARACTERISTICS 


Naval  aviation  mishaps  are  the  inevitable  result  of  the  practice  of  aviation.  The 
Navy  and  other  services  continue  to  strive  for  a  reduced  aviation  mishap  rate  through 
numerous  safety  programs.  The  Naval  Aviation  Safety  Program  is  one  such  program 
responsible  for  reductions  in  aircraft  accidents  through  the  careful  investigation, 
documentation  and  analysis  of  aircraft  accidents.  Mishaps  occur  for  numerous  reasons, 
and  those  reasons  are  a  mystery  until  the  evidence  is  collected  and  interpreted  by  a  board 
of  investigators. 

The  Naval  Aviation  Safety  Program,  OPNAV  instruction  3750.6Q  directs  the 
conduct  of  naval  aviation  mishap  investigations  including  the  initial  reporting  of  the 
mishap,  the  collection  of  evidence,  and  the  formal  publication  of  the  final  investigation 
and  accompanying  supporting  evidence.  The  success  of  the  Naval  Aviation  Safety 
Program  is  attributable  to  the  Naval  Safety  Center's  ability  to  organize  and  examine 
aggregate  data  collected  from  mishap  investigations.  Reduced  mishap  rates  are  the  result 
of  direct  actions  taken  in  response  to  mishap  investigations,  and  to  achieve  this  the 
investigations  are  highly  structured  and  programmed.  This  high  level  of  structure  allows 
analysts  to  identify  dangerous  trends  and  mandate  immediate  changes  to  operational 
procedures  and  training  when  necessary.  The  mishap  rate  of  50  mishaps  per  100,000 
flight  hours  in  the  first  reporting  of  accidents  in  the  1950s  of  has  dropped  to  1.96  in  May 
of  1995  because  of  this  ongoing  analysis  and  data  collection  [Naval  Safety  Center 
Statistics], 

Military  aviation  mishaps  share  the  common  elements  of  accidents  and  mishaps 
that  occur  in  other  contexts,  but  the  military  environment  and  the  OPNAVINST  3750.6Q 
mandates  place  extraordinary  pressures  on  the  mishap  investigator  and  investigative  board. 
The  most  significant  of  these  pressures  explained  in  more  detail  below  are  uncertainty, 
time  constraints,  and  the  unique  administrative  burdens  imposed  on  an  Aviation  Mishap 
Board  (AMB)  during  the  course  of  a  mishap  investigation. 
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1.  Uncertainty 

Uncertainty  exists  at  many  different  levels  in  the  mishap  investigation.  Obviously, 
the  primary  source  of  uncertainty  in  mishap  investigation  is  the  evidence  presented  with 
unanswered  causes.  It  is  the  goal  of  the  Aviation  Mishap  Board  to  deliberate  upon  the 
evidence  and  accurately  identify  the  hazards  to  naval  aviation  defined  by  the  evidence. 
Although  the  members  of  the  Aviation  Mishap  Board  are  experts  in  areas  such  as  aircraft 
operations  and  maintenance,  they  may  lack  the  expert  knowledge  required  to  interpret, 
organize  and  investigate  evidence  presented  by  outside  sources.  The  AMB  is  thus 
responsible  for  it's  own  training  as  well  as  the  tasks  associated  with  active  mishap 
investigation.  The  level  of  this  training  introduces  additional  uncertainty  defined  by  the 
competence  of  the  board.  A  required  member  of  any  Navy  AMB  is  the  Aviation  Safety 
Officer  (ASO)  who  is  specially  qualified  to  reduce  this  type  of  uncertainty  by  training  the 
board  members  and  "translating"  expert  data  to  facilitate  deliberations. 

An  additional  source  of  uncertainty  is  introduced  by  the  nature  of  the  mishap. 
Evidence  left  in  the  wake  of  a  mishap  may  not  immediately  point  to  obvious  causes  but 
their  careful  organization  may  imply  numerous  event  "chains"  which  the  AMB  must 
consider.  Often  those  mishaps  which  leave  little  physical  evidence  become  difficult  to 
investigate  because  the  number  of  causal  factors  cannot  be  eliminated  based  on  evidence. 
In  these  cases  an  AMB  must  develop  many  different  scenarios  which  point  to  sources  of 
evidence  and  then  deliberate  on  the  validity  of  each.  How  these  facts  relate  to  each  other 
and  how  the  scenarios  are  inter-  related  produces  uncertainties  which  require  the  AMB  to 
have  an  organized  strategy  for  organizing  and  recording  deliberations.  An  AMB  which 
proceeds  with  an  investigation  without  a  strategy  for  documenting  it's  own  deliberations 
will  revisit  uncertainties  and  questions  numerous  times  resulting  in  inefficiencies  and 
inaccuracies  in  logic.  The  central  topic  of  this  thesis,  the  deliberation  model,  directly 
addresses  the  above  discussed  uncertainties.  A  supporting  application  development  is 
suggested  around  this  model  to  address  other  important  problems  faced  by  the  AMB. 
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These  include  time  constraints  and  administrative  overhead.  Other  problems  more  specific 
to  the  deliberation  model  are  discussed  in  Chapter  II  of  this  text. 

2.  Time  Constraints 

The  timely  delivery  of  the  results  of  an  investigation  are  critical  to  the  prevention 
of  similar  mishaps.  As  such,  OPNAVINST  3750. 6Q  requires  completion  of  investigations 
of  specified  severity  within  given  time  periods.  Time  constraints  force  additional  pressures 
on  the  deliberation  process,  and  poorly  managed  mishap  boards  may  produce  inaccurate 
investigations.  Although  the  Mishap  Investigation  Report  is  a  highly  structured  document 
which  forces  the  authors  to  make  logical  connections  between  evidence  and  causal  factors, 
the  Naval  Aviation  Safety  Program  instruction  does  not  suggest  a  clear  strategy  for  board 
deliberation.  Without  such  a  strategy,  the  time  constraints  placed  on  the  investigating 
body  not  only  tax  the  organizational  structure  of  the  board  and  the  personal  skills  of  the 
ASO,  but  they  may  also  affect  the  quality  of  the  investigation.  The  deliberation  model 
developed  in  this  thesis,  together  with  the  suggested  additional  modules  of  the  decision 
support  system,  will  aid  the  AMB  in  reaching  timely,  logically  accurate  conclusions. 
Although  not  implemented  here,  the  mishap  reporting  process  can  be  greatly  enhanced  by 
the  implementation  of  the  database  portion  of  the  decision  support  system.  This 
implementation  would  automate  many  of  the  message  reporting  procedures  making  the 
time  constraints  placed  on  a  mishap  board  less  significant. 

3.  Administrative  Overhead 

The  Secretary  of  the  Navy  assigns  the  mishap  reporting  and  investigative  tasks  to 
the  "reporting  custodian"  of  the  aircraft  involved  in  the  mishap  [OPNAVINST  3750.6Q], 
Safety  instructions  and  directives  require  the  existence  of  a  standing  mishap  board,  but 
often  squadron  or  activity  resources  do  not  allow  the  assignment  of  the  administrative 
support  necessary  for  a  major  investigation  on  a  permanent  basis.  As  a  result,  the 
administrative  burden  associated  with  the  mishap  investigation  process  can  further 
contribute  to  the  quality  of  the  investigative  results  as  the  board  assumes  the 
administrative  burdens  of  the  investigation.  In  addition,  the  actual  occurrence  of  mishaps 
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in  aviation  activities  is  not  routine  and  thus  administrative  procedures  may  be  the  results  of 
crisis  management  rather  than  established  procedure.  Although  safety  directives  require 
the  commanding  officer  and  the  ASO  to  conduct  training  and  drilling,  they  cannot  predict 
the  workload  associated  with  the  actual  mishap  occurrence. 

D.  SOLUTION 

Our  proposed  solution  to  the  problem  is  the  implementation  of  a  system  which 
addresses  the  above  problems  of  uncertainty,  time  constraints  and  administrative 
overhead.  This  thesis  addresses  the  entire  mishap  investigation  process  with  a  focus  on 
the  central  issue  of  the  mishap  investigation,  the  deliberation  of  the  board.  We 
concentrate  on  the  development  of  a  "deliberation  model"  because  it  directly  addresses  the 
purpose  of  the  Mishap  Investigation  Report,  that  of  accurately  identifying  hazards  or 
causal  elements.  We  provide  an  example  implementation  of  this  model  to  demonstrate  it's 
usefulness  in  a  simulated  mishap.  In  addition  to  the  development  of  the  deliberation  model 
which  is  the  centerpiece  of  the  DSS,  we  suggest  schemas  for  the  development  of  the 
related  databases  supporting  the  "deliberation  engine".  It  is  the  role  of  these  supporting 
functions  which  will  complete  a  DSS  development  by  automating  the  report  generation 
processes.  In  addition,  we  seek  to  automate  many  of  the  decisions  involving  mishap 
classification  and  rules  in  reporting  defined  by  the  Naval  Safety  Center  Program 
instruction 

This  thesis  presents  a  decision  support  model  which  is  logically  based  and  seeks  to 
aid  the  investigator  in  the  investigative  process.  The  model  does  not  strive  to  automate 
the  decision  making  process,  rather  to  introduce  efficiencies  made  available  by  principled 
information  processing  and  storage.  In  addition,  the  model  presents  a  context  which  is 
visually  based,  and  although  the  implementation  presented  in  this  thesis  does  not  provide  a 
visual  tool,  the  basis  for  the  model  is  best  represented  in  this  graphical  context.  The  thesis 
examines  in  detail  the  problems  of  mishap  investigation  and  focuses  on  the  core  of  the 
proposed  decision  support  system.  Finally,  we  present  a  basic  implementation  using  a 
"canned"  mishap  investigation  and  propose  further  development. 
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H.  DETAILED  DESCRIPTION  OF  THE  PROBLEM 


A.  THE  NAVAL  AVIATION  SAFETY  PROGRAM 

OPNAV  instruction  3750.6Q  is  the  current  version  of  the  instruction  governing  the 
mishap  investigation  process.  The  mandate  of  this  instruction  is  much  broader,  however 
and  includes  most  aspects  of  the  Naval  Aviation  Safety  Program  including  the  conduct  of 
individual  aviation  command  safety  programs.  This  thesis  enhances  the  purpose  of  the 
Naval  Aviation  Safety  Program  by  improving  the  mishap  investigation  process  as  defined 
in  the  3750.6Q  instruction.  The  instruction  states  this  purpose  on  page  1-1 : 

"The  purpose  of  the  Naval  Aviation  Safety  Program  is  to  preserve 
human  and  material  resources.  The  program  enhances  operational 
readiness  by  preserving  the  resources  used  in  accomplishing  naval  aviation 
missions.  The  human  resources  include  professional  pride,  high  morale, 
physical  well-being,  and  life  itself,  all  of  which  are  susceptible  to  damage 
and  destruction  by  mishaps.  The  material  resources  include  all  kinds  of 
property  which  might  be  damaged  by  a  naval  aircraft  mishap,  such  as  naval 
aircraft,  ships,  weapons,  and  facilities.  The  Naval  Aviation  Safety  Program 
thus  directly  supports  all  aspects  of  naval  aviation.  Resources  other  than 
naval  aviation  resources  may  be  preserved  through  success  of  the  program, 
and  knowledge  gained  in  the  program  may  assist  other  safety  efforts.  The 
program,  therefore,  yields  benefits  beyond  its  scope." 

The  instruction  further  defines  the  objective  of  the  program  on  page  1-1 : 

"The  purpose  of  the  Naval  Aviation  Safety  program  is  accomplished 
by  the  prevention  of  damage  and  injury.  Potential  causes  of  damage  and 
injury  are  termed  hazards.  The  objective  of  the  Naval  Aviation  Safety 
Program  is  to  eliminate  hazards." 

The  Program  seeks  to  eliminate  hazards  through  their  identification,  and  mishap 
investigation  is  one  of  the  primary  vehicles  for  this  identification.  In  addition  to  the 
understanding  of  the  Program  and  Objectives,  this  thesis  utilizes  some  basic  concepts  and 
definitions  reviewed  in  section  105  of  the  instruction.  We  base  much  of  the  deliberative 
model  on  the  following  concepts  defined  in  the  instruction: 
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♦  Necessitarianism.  The  doctrine  that  events  are  inevitably  determined  by  preceding 
causes,  and  the  corollary  that  events  may  be  prevented  by  the  elimination  of  their 
causes. 

♦  Damage  and  Injury  are  the  events  to  be  eliminated  and  thus  the  causes  of  damage 
and  injury  may  be  prevented  by  eliminating  their  causes. 

The  causes  of  damage  and  injury  are  hazards  and  thus  the  purpose  of  the  program 
is  to  eliminate  hazards.  Logically,  the  ideal  outcome  of  the  Naval  Aviation  Safety 
Program  would  be  the  elimination  of  all  hazards  or  causes  of  mishaps.  By  this  definition,  a 
mishap  is  a  failure  of  the  Naval  Aviation  Safety  Program.  The  instruction  describes  the 
importance  of  the  sequences  of  prescribed  action  necessary  both  before  and  after  the 
occurrence  of  a  mishap;  when  these  actions  occur  after  the  mishap,  their  purpose 
becomes  that  of  preventing  a  recurrence.  The  instruction  defines  these  actions  specifically 
on  page  1-3  as  "hazard  detection"  and  "hazard  elimination". 

Hazard  detection  and  elimination  after  a  mishap  are  the  responsibility  of  the 
permanent  Aircraft  Mishap  Board  (AMB)  appointed  by  the  reporting  custodian  of  the 
aircraft  involved.  The  purpose  of  this  board  is  specifically  to  "detect  hazards  through 
mishap  investigation"  [OPNAVTNST  3750. 6Q].  The  instruction  further  states  provisions 
for  hazard  reporting  after  the  mishap  in  the  form  of  the  Mishap  Investigation  Report 
(MIR)  which  is  required  for  all  defined  naval  aircraft  mishaps.  The  MER  is  the  final 
product  of  the  AMB  and  serves  the  primary  purpose  of  hazard  identification.  In  addition 
to  this  identification,  the  AMB  provides  recommendations  for  the  elimination  of  the 
identified  hazards  through  formal  recommendations  of  corrective  actions  which  require 
documented  action.  Thus  the  AMB  becomes  a  powerful  force  in  the  elimination  of 
identified  hazards  after  their  identification. 

B.  PROGRAM  PARTICIPANTS 
1.  The  Senior  Member 

The  investigation,  deliberation  and  formulation  of  the  Mishap  Investigation  Report 
fall  under  the  responsibility  of  the  Aviation  Mishap  Board  (AMB).  The  Naval  Aviation 
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Safety  Program  instruction  requires  reporting  custodians  (usually  commanding  officers  of 
aviation  squadrons)  to  appoint  and  maintain  a  standing  AMB.  Technically,  the  reporting 
custodian  must  also  appoint  an  AMB  "senior  member"  to  take  responsibility  for  the 
training  and  readiness  of  the  AMB  but  the  senior  member  is  usually  the  reporting 
custodian  (also  the  commanding  officer).  The  Senior  Member  acts  as  the  "chairman"  of 
the  board  and  is  ultimately  responsible  for  a  given  mishap  investigation. 

2.  The  Aviation  Safety  Officer 

The  Aviation  Safety  Officer  (ASO)  is  a  designated  naval  aviator  or  naval  flight 
officer  who  is  a  graduate  of  the  "Aviation  Safety  School".  The  ASO  is  a  participating 
pilot  or  flight  officer  in  the  primary  mission  of  the  squadron  and  possesses  additional 
training  as  a  specialist  in  the  Naval  Aviation  Safety  Program  from  the  Naval  Aviation 
Safety  School  at  the  Naval  Postgraduate  School.  The  ASO  school  also  provides  the  ASO 
with  specialized  training  in  such  areas  as  wreckage  examination,  structural  engineering, 
human  factors  in  mishap  investigations,  and  the  conduct  of  mishap  investigation  and 
reporting.  Although  the  training  and  maintenance  of  the  AMB  is  the  responsibility  of  the 
Senior  Member  of  the  AMB,  since  the  Senior  Member  is  usually  also  the  commanding 
officer,  these  responsibilities  are  typically  delegated  to  the  ASO. 

In  the  context  of  an  actual  mishap,  the  ASO  is  the  primary  functionary  in  the 
investigation  process.  The  ASO  possesses  the  basic  knowledge  and  acts  as  the  translator 
between  the  technical  experts  and  the  AMB  members.  The  ASO's  task  is  similar  to  that  of 
a  lawyer  in  a  courtroom,  he  must  take  highly  technical  data  and  evidence  from  expert 
investigators  and  translate  it  to  the  level  of  expertise  of  the  AMB.  This  often  requires  that 
the  ASO  provide  training  for  the  AMB  in  certain  areas  to  facilitate  clear  understanding  of 
the  evidence.  In  addition,  the  ASO  is  responsible  for  the  accurate  collection  and 
interpretation  of  evidence  by  technical  sources.  The  ASO  school  training  seeks  to  prepare 
ASOs  for  this  by  providing  a  level  of  training  which  will  make  the  ASO  at  least  conversant 
in  the  technical  areas  encountered  in  mishap  investigations.  Experts  such  as  Naval  Safety 
Center  investigators  and  design  engineers  do  not  participate  in  the  deliberations  of  the 
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AMB  in  a  mishap,  they  only  provide  evidence  on  which  the  AMB  deliberates.  It  remains 
the  responsibility  of  the  ASO  to  provide  the  evidence  to  the  appropriate  experts  and  then 
return  them  for  AMB  deliberations. 

3.  The  Aviation  Mishap  Board 

The  Naval  Aviation  Safety  Program  governing  instruction  requires  that  each 
"reporting  custodian"  maintain  a  standing  Aviation  Mishap  Board.  Paragraph  206  (pp.2-4 
to  2-6)  states  that  the  members  shall  be  appointed  by  name  and  in  writing  by  the 
designated  appointing  authority.  The  AMB  is  basically  composed  of  active  duty, 
commissioned  officers  of  the  USN  or  USMC.  At  a  minimum  the  board  must  include  four 
officers  including  a  Senior  Member,  an  ASO,  a  flight  surgeon,  an  officer  well  qualified  in 
aircraft  maintenance  and  an  officer  well  qualified  in  aircraft  operations.  If  necessary,  the 
appointing  authority  may  designate  members  from  outside  the  command  if  experienced  or 
qualified  officers  are  not  available  within  the  command.  In  addition,  for  mishaps  involving 
aircraft  manned  by  aircrew,  the  board  shall  consist  of  at  least  one  officer  who  is  qualified 
in  that  particular  model  of  aircraft.  Typically,  squadrons  or  aviation  activities  maintain 
mishap  boards  composed  of  four  to  ten  officers,  and  include  designated  alternate  members 
to  replace  primary  members  who  might  not  be  available  at  the  time  of  a  mishap. 

The  Senior  Member  of  the  AMB  ensures  (through  the  ASO)  that  the  board  is 
trained  and  prepared  for  a  Mishap.  This  training  is  formalized  in  A  "pre-mishap"  plan 
which  serves  as  a  contingency  plan  for  implementation  in  the  event  of  a  mishap.  The  plan 
serves  as  the  training  document  for  the  AMB  and  anticipates  "all  reasonable  eventualities" 
encountered  in  the  aftermath  of  a  mishap  and  attempts  to  cope  with  these  eventualities. 
Site  security,  media  coordination,  area  law  enforcement,  and  wreckage  preservation  are 
just  a  few  of  the  issues  addressed  in  the  pre-mishap  plan.  A  decision  support  system 
implementation  would  necessarily  become  part  of  this  plan:  And  the  Pre-Mishap  plan 
should  address  hardware,  software  and  connectivity  as  appropriate  to  the  computing 
environment  on  which  the  system  is  implemented. 
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4.  Other  Experts 

Section  603f  and  section  608  of  OPNAVINST  3750. 6Q  describe  sources  of 
assistance  outside  the  resident  AMB  which  a  Senior  Member  may  request  during  the 
course  of  an  investigation.  The  Chief  of  Naval  Operations  may  mandate  a  Naval  Safety 
Center  investigation,  or  the  AMB  may  request  investigative  assistance.  The  Naval  Safety 
Center  provides  professional  investigators  to  the  AMB  and  serves  as  another  source  of 
evidence  when  requested  or  mandated.  This  investigative  assistance  does  not  absolve  the 
AMB  of  responsibility,  it  only  enhances  the  ability  of  the  board  in  high-  profile  or  difficult 
investigations.  In  addition  to  investigative  assistance,  an  AMB  may  request  technical  and 
medical  assistance  from  other  defense  agencies.  The  sources  of  this  assistance  are  varied, 
they  range  from  engineering  assistance  from  government  laboratories  to  forensic 
pathology  evaluations  from  the  Armed  Forces  Pathology  Institute.  Since  there  is  often  a 
"knowledge  gap"  between  the  expert  assistance  and  the  AMB  knowledge  base,  ASOs  are 
trained  in  the  more  common  areas  to  understand  the  technical  results  and  translate  them 
for  the  AMB.  The  results  of  expert  assistance  are  advisory  and  the  AMB  deliberations 
treat  all  assistance  as  evidence. 

C.  MISHAP  INVESTIGATION 

In  designing  a  decision  support  system  for  aviation  mishap  investigation,  the  task 
of  this  thesis  is  simplified  by  the  highly  structured  requirements  of  the  Naval  Aviation 
Safety  Program.  In  seeking  to  identify  the  cause  factors  in  a  mishap  the  program  requires 
the  final  product,  or  the  Mishap  Investigation  Report  be  in  a  rigid  format  which  requires 
logical  support  for  arguments.  The  program  instruction  does  not  however,  provide 
guidelines  for  detailed  deliberation  and  decision  making  techniques  beyond  the  formatting 
of  the  final  product.  The  Safety  Program  does  not  provide  guidance  for  the  investigation 
process.  The  Senior  Member,  the  ASO  and  the  members  of  the  AMB  are  left  to  determine 
a  strategy  for  evidence  collection,  cataloging  and  deliberation.  This  thesis  takes  advantage 
of  the  MIR  structure  to  develop  the  deliberation  model. 
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The  deliberation  model  developed  in  this  thesis  does  not  require  a  detailed 
description  of  naval  mishap  classes.  As  background  however,  the  reader  should 
understand  that  mishap  classes  are  categorized  by  severity  based  on  monetary  losses  and 
human  casualties,  and  also  by  types  of  occurrences  such  as  flight  mishaps  and  ground 
mishaps.  The  most  severe  mishaps  are  class  "A"  and  require  the  most  stringent  reporting 
requirements.  Class  A  mishaps  require  the  AMB  to  respond  more  quickly  with  an  initial 
report  and  subject  the  final  report  to  detailed  review  not  required  of  lower  classifications 
of  mishaps.  Our  model  development  targets  the  environment  encountered  in  the 
investigation  and  reporting  of  a  Class  A  mishap  but  is  germane  to  other  investigations  as 
well.  The  basic  elements  of  the  model  are  common  to  all  naval  aviation  mishap  and  hazard 
investigations. 

1.  The  Mishap  Investigation  Report 

The  Mishap  Investigation  Report  (MIR)  is  the  result  of  the  deliberations  of  the 
Aviation  Mishap  Board  following  a  naval  aviation  mishap.  The  purpose  of  the  MIR  is  to 
report  and  document  the  hazards  which  were  the  cause  of  the  mishap  and  damage  and 
injury  which  may  have  occurred  in  the  course  of  the  mishap  (sec  702).  The  MIR  develops 
a  list  of  evidences  into  "detailed  cause  factors"  through  a  series  of  logical  steps,  and  these 
cause  factors  are  the  end  result  of  the  mishap  investigation.  Once  the  MIR  is  completed, 
the  AMB  publishes  it  as  a  naval  message.  As  the  message  passes  "up  the  chain  of 
command",  each  endorser  comments  on  the  investigation  and  addresses  specific 
recommendations  made  by  the  board.  A  more  detailed  description  of  the  process  is 
represented  in  figure  2-1. 

a.  Evidence 

After  the  occurrence  of  a  mishap,  an  initial  message  is  published  and  the 
formal  investigation  convenes  the  AMB.  The  AMB  eventually  collects  the  evidence, 
deliberates  and  then  publishes  the  MIR.  The  first  significant  section  of  the  MIR  is  the 
evidence  section.  The  investigative  process  results  in  a  list  of  evidences  which  are 
categorized  in  the  MIR  in  a  summary  format.  Each  piece  of  evidence  is  part  of  an 
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"enclosure"  which  denotes  the  location  of  the  described  physical  evidence.  The  evidence 
section  thus  contains  the  factual  data  in  the  mishap  describing  all  of  the  relevant  evidence 
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Figure  2-1  Mishap  Information  Flow 


in  the  investigation  from  all  sources. 

b.  Analysis 

The  next  section  of  the  MIR  contains  the  analysis  paragraph.  The  AMB 
documents  the  investigation  by  separating  the  mishap  into  "factors"  which  it  either  accepts 
or  rejects.  The  given  factors  are  described  as  aircrew,  supervisory,  facilities, 
maintenance  or  material  and  must  be  based  on  the  evidence  included  in  the  previous 
section.  Section  716  of  the  Safety  Program  instruction  describes  each  rejected  or 
accepted  factor  as  a  "scenario"  which  is  tested  by  the  board  in  light  of  the  evidence.  This 
section  includes  a  summary  of  each  scenario  by  describing  the  deliberations  of  the  AMB  in 
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reaching  their  conclusions.  The  instruction  suggests  that  a  useful  technique  for  describing 
these  factors  is  in  chronological  sequence  when  documenting  deliberations. 

a  Conclusions 

The  "conclusions"  section  of  the  MIR  classifies  the  accepted  factors  from 
the  analysis  section  and  determines  their  individual  severity  using  "risk  assessment  codes". 
In  addition,  the  AMB  must  further  classify  each  accepted  factor  as  a  "detailed  cause 
factor"  which  is  the  finest  level  of  classification  in  the  investigation.  The  AMB  must 
translate  each  accepted  factor  to  a  "detailed  cause  factor"  provided  in  appendix  L  of 
OPNAVINST  3750.6Q.  This  list  is  "an  exhaustive  tabulation  of  the  way  in  which  people 
and  aviation  machines  have  historically  interacted  to  produce  mishaps;  as  such  they 
provide  a  menu  of  possible  Human  Factors  that  could  be  involved  in  a  mishap" 
[OPNNAVINST  3750.6Q  p.L-1],  These  cause  factors  are  divided  into  who,  what  and 
why  or  component,  mode  and  agent  categories  and  serve  to  contribute  to  the  Naval  Safety 
Center's  mishap  data  file.  The  AMB  chooses  the  "Who/What/Why"  tabulated  cause 
factors  most  appropriate  to  each  developed  factor  accepted  in  the  analysis,  and  this  set  of 
factors  represents  the  final  outcome  of  the  mishap  investigation  process.  A  separate 
section  of  the  MIR  includes  causal  factors  causing  other  damage  or  injury  in  the  mishap 
which  are  indirect  results  of  the  mishap.  This  section  uses  a  slight  variant  of  the  process 
described  above. 

D.  THE  INVESTIGATION  PROBLEM 
1.  Example  Presentation 

OPNAV  Instruction  3750.6Q  provides  the  following  fictitious  example  to  present 
message  formatting: 

"Scenario:  GEAR-UP  LANDING 

A  multi-piloted  aircraft  joined  the  landing  pattern.  The  aircrew 
consisted  of  pilot  (aircraft  commander),  and  copilot  (pilot  qualified  in 
model).  The  copilot,  a  brand  new  nugget  recently  reported,  read  the 
landing  checklist  and  the  pilot,  a  seasoned  veteran  of  intimidating 
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demeanor,  executed  it.  The  pilot  put  the  landing  gear  handle  in  the  down 
position  but  did  not  check  the  gear  position  indicators.  They  showed  the 
gear  up,  and  neither  pilot  noticed  the  gear  warning  light  which  was 
illuminated.  The  gear  was,  in  fact,  up.  That  particular  aircraft  was 
equipped  with  a  warning  horn  which  sounded  when  the  throttle  was 
retarded  to  a  descent  setting  and  the  landing  gear  was  up.  The  horn  failed 
to  sound  when  the  pilot  retarded  the  throttle  at  the  180.  The  aircraft 
subsequently  landed  gear-up  with  Class  "B"  damage. 

The  following  facts  were  discovered  in  the  ensuing  investigation: 

The  pilot  had  only  four  hours  sleep  the  previous  night  because  he  worked 
late;  the  pilot's  father  had  died  the  month  before;  maintenance  work  done 
previous  to  the  flight  had  been  in  accordance  with  directives  but  a 
significant  step  was  omitted  from  the  maintenance  handbook  which  allowed 
the  gear  handle  to  be  lowered  without  lowering  the  gear;  an  emergency 
backup  to  lower  the  gear  was  available  but  not  used;  a  microswitch  inside 
the  throttle  quadrant  was  found  corroded  and  failed  as  an  open  circuit,  the 
microswitch  activated  the  warning  horn  system;  the  normal  climate  at 
homebase  at  that  time  of  year  was  wet  an  rainy,  the  aircraft  had  not  been 
hangared  on  a  regular  basis  which  was  not  required."  [3750. 6Q,  p.  M-l] 

The  purpose  of  the  above  example  mishap  is  to  illustrate  the  process  of  taking 
evidence  discovered  in  the  course  of  the  mishap  investigation  to  compose  paragraphs  10 
through  13  of  the  MIR  [3750. 6Q,  p.  M-l].  The  authors  of  the  instruction  admit  the 
example  is  hypothetical,  brief  and  contains  many  logical  errors,  and  thus  serves  this 
discussion  well  in  pointing  out  the  utility  of  the  model.  The  "facts"  or  evidence 
discovered  during  this  example  investigation  are  incomplete  and  useful  for  illustrating  the 
deliberation  model.  The  discussion  will  argue  the  utility  of  the  deliberation  model  based 
on  this  example,  and  draw  additional  inferences  which  might  aid  the  fictitious  Aviation 
Mishap  Board  investigating  this  mishap.  During  the  subsequent  discussion,  we  will 
repeatedly  refer  directly  to  this  example  to  enhance  selected  themes. 

2.  Why  is  there  the  Need  for  an  Automated  Deliberation  Process? 

The  focus  of  this  thesis  is  the  development  of  the  deliberation  model.  The 
presentation  of  the  underlying,  formalized  principles  provides  a  reference  for  future 
implementations  of  decision  support  systems  using  this  simple  logic  with  advancing 
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technology.  Automation  of  the  deliberation  process  addresses  the  "macro"  problems  in 
Chapter  1,  and  we  can  specifically  state  influences  on  the  deliberation  process  likely  to 
affect  the  deliberation  process.  Three  of  these  are  "selective  inattention",  bias  and  logical 
errors  encountered  in  deliberations. 

a.  Selective  Inattention 

Selective  inattention  or  cognitive  filtering  acts  to  "hide"  evidence  or 
probable  causes  based  on  any  number  of  influences.  [Frew,  1995  ]  The  unconscious  act  of 
selectively  omitting  or  discarding  relevant  information  in  any  context  leads  to  poor 
decision  making,  or  in  this  case,  inaccurate  deliberation.  Selective  inattention  may  be  the 
result  of  the  opinions  of  an  influential  AMB  member,  or  it  may  result  simply  from  various 
pressures  put  collectively  on  an  AMB  or  it's  members.  For  example,  squadron  loyalty  and 
pride  may  make  the  deliberations  of  an  AMB  difficult  if  the  reputation  of  a  popular 
commander  is  marred  by  results.  As  the  AMB  deliberates,  they  might  selectively  and 
unconsciously  omit  any  chain  of  events  which  may  point  to  the  commander.  The 
organized  approach  presented  by  the  deliberation  model  forces  a  continuous  process  of 
inquiry  which,  if  properly  implemented,  will  address  selective  inattention. 

b.  Bias 

If  the  AMB  deliberates  an  investigation  in  an  unstructured  manner,  the 
possibility  of  deliberate  bias  becomes  much  greater.  Although  the  concept  of  "privilege" 
[OPNAV  3750.6Q  p.  1-5]  protects  witnesses  who  provide  evidence  in  a  mishap,  this 
concept  cannot  fully  protect  the  findings  of  a  board.  Deliberations  which  result  in 
politically  sensitive  or  volatile  conclusions  can  face  external,  deliberate  pressures  which 
affect  board  members  consciously  and  unconsciously.  In  the  extreme,  a  biased  member 
can  deliberately  try  to  direct  or  sway  deliberations,  and  the  Senior  Member  might  not 
detect  this  if  he  does  not  organize  and  document  the  deliberation  process.  Biased 
conclusions  will  not  develop  logically,  and  credible  evidence  will  not  support  them.  This 
deliberation  model  presents  a  causal  flow  and  evidence  assignment  which  exposes  such 
bias. 
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a  Logical  Errors 

A  logical  approach  to  mishap  investigation  is  not  difficult,  and  yet  logical 
errors  cause  AMBs  to  re-  deliberate  and  re-visit  issues  unnecessarily.  Unfortunately  the 
reporting  custodians  of  aircraft  involved  in  a  mishap  (commanding  officers)  who  release 
flawed  investigations  receive  immediate  feedback  from  Senior's  endorsements,  making 
their  logical  errors  very  public.  The  model  presented  here  assumes  the  AMB  commits 
logical  errors  when  they  fail  to  adequately  support  a  conclusion  based  on  a  probable 
cause,  or  inadequately  support  a  probable  cause  with  evidence.  In  addition,  the  AMB  can 
commit  logical  errors  by  not  completing  the  investigation,  i.  e.  the  board  fails  to  seek 
evidence  to  support  the  most  "detailed"  probable  cause  at  the  end  of  a  "chain  of  events". 
The  quoted  example  provides  an  illustration  of  this  type  of  error:  Although  the  board 
discovered  that  the  pilot  had  only  four  hours  sleep  the  previous  night,  the  board  failed  to 
continue  the  investigation  and  consider  why  he  was  awake.  This  approach  might  force 
the  board  to  investigate  the  possibility  of  a  physiological  or  psychological  problem  the 
pilot  suffered  rather  than  accepting  the  lack  of  sleep  as  the  root  cause. 

In  this  chapter,  we  have  presented  the  detailed  description  of  the  problem  of  mishap 
investigation,  focusing  on  the  deliberation  process  (or  lack  thereof).  We  have  attempted 
to  illustrate  some,  but  not  all  of  the  problems  associated  with  an  unorganized  approach  to 
the  deliberation  of  the  AMB.  Current  directives  leave  the  deliberation  process  open  to 
interpretation  and  yet  this  process  should  be  the  basic  building  block  of  any  mishap 
investigation.  This  theme  is  recognized  by  the  professional  instruction  staff  at  the  Aviation 
Safety  School  and  this  staff  attempts  to  address  this  lack  of  methodology  in  the  instruction 
given  to  Aviation  Safety  Officers.  This  instruction  serves  as  a  basis  for  the  subsequent 
model  development. 

The  deliberation  model  is  the  center  of  the  thesis,  but  it  is  supported  by  other 
modules  of  the  entire  system.  These  modules  seek  to  address  the  problems  discussed  in 
Chapter  1,  and  their  implementation  is  discussed  in  the  following  chapter  in  advance  of  the 
detailed  deliberation  model  development.  The  discussion  of  the  system  development  lays 
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the  foundation  and  provides  many  of  the  assumptions  germane  to  the  deliberation  module 
and  model  discussions  which  follow  in  the  subsequent  chapter. 
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m.  A  DECISION  SUPPORT  SYSTEM  FOR  NAVAL  MISHAP  INVESTIGATION 


A.  SYSTEM  OVERVIEW 


Figure  3-1  Application  Architecture 


1.  General  description  and  requirements 

Figure  3-1  describes  the  overall  proposal  for  the  complete  decision  support  system. 
Developers  may  follow  this  architecture  in  a  single  application  treating  each  separate  box 
as  a  module,  but  the  client/  server  approach  best  satisfies  the  requirements  of  this 
application.  Specifically,  the  above  proposal  suggests  "database  server"  type  architecture 
commonly  referred  to  in  client/  server  terminology  [Orfali,  Harkey  and  Edwards,  1995]. 
The  requirements  of  the  system  are  basic.  They  simply  automate  the  mishap  reporting 
process.  In  addition,  the  system  shall  aid  the  AMB  in  the  deliberation  process.  The  client/ 
server  architecture  facilitates  the  standardization  of  data,  the  portability  of  individual 
component  applications  and  data,  and  the  ability  to  develop  and  easily  implement 
additional  applications  based  on  future  requirements.  In  addition,  the  intelligent  and 
careful  development  of  the  server  database  might  provide  interface  with  other  activity 
functional  databases  such  as  personnel  or  maintenance  departments. 
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Application  X 
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Figure  3-2  Distributed  Environment 


A  stand-alone  or  single  platform  client/  server  implementation  similar  to  Figure  3-1 
utilizes  a  single  database.  Implementations  which  involve  distributed  computing 
environments  such  as  the  "detachment  scenario"  described  in  Figure  3-2  might  require  a 
slightly  different  architecture  in  which  remote  client  applications  communicate  with  a 
command  server.  Often,  naval  aviation  squadrons  or  activities  are  tasked  with  operations 
over  a  large  geographical  area,  necessitating  the  establishment  of  temporary  "detachment" 
sites  which  serve  as  sub-  commands  of  a  parent.  In  these  situations,  the  parent  command 
may  delegate  many  of  the  reporting  and  investigative  tasks  to  the  detachment  commander, 
but  the  message  release  authority  and  central  administration  functions  reside  at  the  central 
command  location.  Necessarily,  developers  would  attach  a  maintainable,  local  database 
capability  at  the  detachment  site  which  would  communicate  with  the  command  server 
system  for  database  updates  and  mishap  investigation  administration  such  as  revision  and 
modification  of  mishap  investigation  messages.  This  type  of  client/  server  architecture  is 
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described  by  a  distributed  data  management  model  which  allows  the  client  application  to 
manage  the  presentation,  application  logic  and  data  management,  and  tasks  the  server  with 
data  management  only  [Orfali,  Harkey  and  Edwards,  1994],  If  the  command  location  is 
also  an  operational  site,  then  the  command  will  become  a  client  and  also  maintain  the 
server  and  associated  DBMS.  This  cooperative  processing  allows  the  generation  of  the 
final  investigation  product  at  any  detachment  or  client  site  while  the  server  platform 
provides  the  squadron-  wide  database  services. 

B.  MODULE  OR  APPLICATION  DEVELOPMENT 

1.  Server  and  Database  Design 

The  OPNAV  3750. 6Q  instruction  provides  a  reference  for  database  development. 
A  careful  examination  of  the  database  model  presented  in  Appendix  A  will  illustrate  our 
strategy  of  providing  a  reusable  database  while  replicating  the  data  elements  required  by 
our  deliberation  application  presented  in  Chapter  IV,  and  other  specific  elements  required 
by  the  system  we  propose  in  this  chapter.  In  addition  to  this  semantic  table,  the  ANSI 
SQL-92  Schema  is  included  in  Appendix  B.  An  examination  of  the  mishap  and  mishap 
investigation  message  formats  suggests  some  of  these  data  objects  such  as  Evidence, 
Factors  and  Cause  Factors.  This  thesis  follows  the  semantic  object  database  design 
approach  and  we  develop  the  schema  based  on  the  semantic  object  modeling  in  Appendix 
B. 

The  development  of  the  above  schema  seeks  to  provide  data  elements  common  to 
a  mishap  with  reuse  by  other  squadron  activities  in  mind.  For  example,  a  maintenance 
department  data  application  might  make  use  of  the  "Aircraft'*  object,  or  an  administrative 
office  might  utilize  the  "person"  object.  We  developed  this  particular  schema  to  support 
the  applications  treated  in  this  thesis,  however,  and  future  developers  may  consider 
modifications  appropriate. 
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2.  Initial  Reporting 

The  initial  reporting  application  should  provide  the  timely  release  of  the  initial 
mishap  message  and  voice  reports  according  to  the  limits  specified  in  the  OPNAV  3750 
series.  This  application  will  also  set  the  default  information  for  a  particular  mishap  and 
automate  the  decisions  associated  with  the  classification  of  a  mishap.  To  produce  the 
initial  mishap  message  and  voice  report  alone,  the  message  drafter  must  make  numerous 
significant  decisions  requiring  the  reference  of  the  OPNAV  3750  instruction: 

•  The  existence  of  a  "defined"  naval  mishap, 

•  The  category  of  the  mishap  as  described  by  paragraph  401  of  OPNAV  3750, 

•  The  severity  of  the  mishap  as  described  by  paragraph  413. 

Specifically,  these  decisions  are  formally  represented  in  the  decision  trees  located 
in  the  Appendix  A  of  Chapter  IV  of  the  instruction  and  provide  developers  with  a  template 
for  the  decision  code  generation.  Readers  should  review  this  instruction  and  the 
associated  decision  trees  for  further  information. 

An  excellent  example  of  an  implementation  of  the  decision  logic  of  the  3750 
instruction  was  developed  by  LT  Hugh  Brian  while  assigned  at  the  Naval  Aviation  Safety 
School  in  June  of  1995.  His  implementation  was  accomplished  using  the  Delphi  Rapid 
Application  Development  tool  and  the  language  used  is  ObjectPascal.  We  present  this 
implementation  as  an  excellent  example  of  an  application  supporting  the  initial  reporting 
phase  of  a  mishap.  Although  the  application  does  not  support  the  client  server 
architecture  described  here,  the  interface  and  decision  mechanisms  provide  templates  for 
future  development. 

The  application  "Notebook"  provides  the  user  with  a  number  of  important 
features.  Brian  allows  the  user  to  set  default  values  which  are  locally  preserved  for  future 
use.  Among  these  values  are  "Officer  Recall",  and  default  squadron  information.  The 
following  figures  present  the  screens  developed  by  LT  Brian  in  the  Mishap  Notebook 
application.  In  addition,  the  application  contains  a  built-  in  template  for  the  initial  message 
generation  and  the  capability  to  store  that  information  as  a  text  or  message-  formatted  file. 
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The  application  also  provides  the  user  with  the  capability  to  generate  an  "OPREP" 
message  (a  naval  incident  reporting  message)  and  an  "OPREP"  phone  report.  The 
interface  of  the  application  guides  the  user  through  the  process  of  the  initial  mishap 
message  reporting  procedure  (Figures  3-2  and  3-3),  using  a  checklist  to  ensure  the  user 


MISHAP  NOTEBOOK 


Figure  3-3  Notebook  Initial  Info.  Screen 


MISHAP  NOTSMOK 
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Figure  3-4  Notebook  Officer  Recall  Screen 
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Figure  3-5  Notebook  Checklist  Screen 


complete  all  the  required  items.  Figure  3-4  is  the  checklist  screen  implemented  in  the 
application.  This  interface  allows  the  user  to  gage  his  progress  and  also  informs  him/her  of 
the  elapsed  time  with  a  running  clock,  which  continues  to  remind  the  drafter  of  the  time 
requirements. 

a.  The  Mishap  Category  Decision 

Notebook  aids  the  user  in  selecting  the  mishap  category  with  the  interface 
presented  in  Figure  3-5,  the  "Mishap  Cat."  screen.  The  OPNAV  3750  instruction 
provides  a  "decision  matrix"  to  determine  the  mishap  category  based  on  nine  different 
conditions.  In  order  to  aid  the  user  in  selecting  the  correct  mishap  classification,  Brian 
presents  the  user  with  a  series  of  standard  windows  check  boxes  in  a  interview  format. 
The  user's  responses  are  recorded  and  the  program  executes  the  following  Pascal  code  to 
determine  the  correct  category  of  mishap: 
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Figure  3-6  Notebook  Severity  Screen 


procedure  TNoteBookForm.MishapCatDoneClick(Sender:  TObject); 

var 

MishapType,  MishapInjury.TMishapCIass; 

begin 

if  (Damage.ltemlndex  =  0)  or  (Damage.ltemlndex  =  1) 
then  MishapType:=  CiassA; 

if  (Damage.ltemlndex  =  2)  then  MishapType:=ClassB; 
if  (Damage.ltemlndex  =  3)  then  MishapType:=ClassC; 

if  (Injury.ltemlndex  =  0)  or  (Injury. Itemlndex  =  1) 
then  Mishaplnjury:=  CiassA; 
if  (Injury.ltemlndex  =  2)  or  (Injury.ltemlndex  =  3) 
then  Mishaplnjury:=ClassB; 
if  (Injury.ltemlndex  =  4)  then  Mishaplnjury:=ClassC; 

if  (MishapType  =  CiassA)  or  (Mishaplnjury  =  CiassA) 
then  MishapSeverity.ltemlndex:=  0  else 
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if  (MishapType  =  ClassB)  or  (Mishaplnjury  =  ClassB) 
then  MishapSeverity.ltemlndex:=  1  else 
if  (MishapType  =  ClassC)  or  (Mishaplnjury  =  ClassC) 
then  MishapSeverity.ltemlndex:=  2; 

end; 

The  above  code  executes  the  decision  trees  located  OPNAVINST  3750. 6Q 
Specifically,  when  combined  with  the  screen  which  determines  the  "intent  for  flight",  this 
code  executes  the  decision  tree  on  page  4C-1  of  the  above  instruction  titled  "Severity 
Classification".  When  the  user  defines  and  selects  certain  exclusive  check  boxes,  the 
simple  series  of  Pascal  "IF-  THEN”  statements  select  the  correct  category  when  the  button 
is  selected.  Figure  3-5  is  the  screen  implementation  of  the  above  ObjectPascal  code.  The 
".itemlndex"  extensions  indicate  the  objects  which  contain  the  values  of  the  checked  box, 
and  these  returned  values  determine  the  classification  of  the  mishap 

LT  Brian's  application  is  currently  a  stand-alone  version  which  saves 
information  only  to  a  text  or  a  message  file.  It  is  presented  here  as  an  example  of  a 
successful  implementation  of  the  decision  matrices  specified  by  the  Aviation  Safety 
Reporting  instruction.  In  order  to  be  applicable  to  this  system,  however,  developers 
would  need  to  rewrite  this  application  to  include  database  access.  The  Delphi  software 
package  and  it's  object  oriented  approach  to  programming  will  facilitate  conversion  of  this 
type  application  to  include  database  functionality.  In  doing  so,  developers  should  follow 
the  server  schema  presented  below  when  considering  the  local  database  design.  At  this 
thesis  writing,  version  1.1B  of  the  entire  system  is  under  development  at  NPS  attempting 
to  convert  LT  Brian's  application  into  a  "client"  application  in  our  framework  (with  the 
permission  of  the  author).  In  implementation  of  this  system,  we  strive  to  implement  LT 
Brain's  interface  and  design,  rewriting  the  code  to  communicate  with  the  server  database. 
We  also  would  preserve  the  additional  capabilities  included  in  the  Mishap  Notebook 
application  as  part  of  the  entire  system.  LT  Brian's  Mishap  Notebook  application  can  be 
obtained  on  the  internet  at  the  Naval  Postgraduate  School  Aviation  Safety  homepage 


26 


(http//www.nps.navy.mil)  or  from  the  Aviation  Safety  FTP  site  located  at  "nps.navy.mil" 
on  the  internet. 

3.  The  Final  Mishap  Reporting  Application 

Developers  may  include  the  final  reporting  application  with  the  AMB  deliberation 
application  presented  in  the  next  chapter.  If  implemented  separately,  however,  the  Final 
Mishap  Reporting  Application  will  serve  to  produce  the  final  mishap  message  in 
accordance  with  OPNAV  3750.6.  The  database  schema  suggested  for  the  server 
facilitates  the  reuse  of  the  original  message  by  simply  appending  the  latest  version  of  the 
initial  message.  The  referenced  instruction  specifies  the  first  nine  paragraphs  as  those 
appearing  in  the  initial  message  and  the  subsequent  sections  specifically  treat  the  reporting 
of  the  deliberation  and  investigation  of  the  mishap  after  the  initial  report. 

Currently,  version  1.  IB  of  the  Decision  Support  System  in  development  during  the 
writing  of  this  thesis  supports  a  separate  Mishap  generation  application  which  imports 
specific  data  from  the  AMB  deliberation  application  module.  Once  this  information  is 
processed  in  the  final  message  generation  application,  the  user  application  should  prepare 
the  final  message.  We  do  not  address  this  portion  of  the  system  in  detail  because  it  is  a 
simple  application  which  developers  may  easily  implement. 

This  application  should  provide  a  template  function  which  maintainers  can  easily 
update  and  revise.  Ideally,  this  "template  updating"  function  should  reside  in  a  server 
application,  so  the  client  applications  can  receive  new  templates  when  needed.  A  system 
administration  type  function  should  be  integrated  into  the  suite  of  application  included 
with  the  server  maintenance  to  update  templates  and  provide  them  to  client  applications. 

The  following  chapter  presents  the  central  focus  of  this  thesis,  the  deliberation 
application. 
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IV.  THE  DELIBERATION  APPLICATION 


A.  BACKGROUND 

1.  The  Aviation  Safety  School  Model 

The  central  issue  addressed  in  this  thesis  is  the  development  of  the  deliberation 
model  and  a  supporting  application.  This  application  or  functionality  seeks  to  improve  the 
quality  of  the  deliberation  process  during  mishap  investigation  by  providing  an  interaction 
with  the  user  which  will  record  and  organize  the  reasoning  of  the  AMB.  The  goal  is  not 
to  completely  automate  the  decision  process,  rather  to  present  the  user  with  an  organized 
and  proven  strategy  for  effective  presentation  of  the  evidence,  causes  and  conclusions  of  a 
mishap  deliberation. 

The  genesis  of  the  model  we  develop  below  is  a  version  of  "blackboard"  method 
currently  taught  by  Aviation  Safety  School  faculty  to  Aviation  Safety  Officer  trainees  in 
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Figure  4-1  Aviation  Safety  School  Mishap  Investigation  Model 
(Maj.  Tom  Hazard) 
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the  Mishap  Investigation  course.  Major  Tom  Hazard,  USMC  an  instructor  in  Mishap 
Investigation,  uses  the  model  reproduced  from  his  teaching  notes  in  Figure  4-1.  This 
version  of  his  model  includes  the  data  from  the  example  mishap  in  Chapter  I. 

Maj.  Hazard's  model  characterizes  the  methodology  we  follow  in  the  development 
of  a  similar  model  below.  The  model  should  accomplish  the  following  goals  through 
interaction  with  the  agent: 

1 .  It  should  present  the  evidence  and  facts  in  the  form  of  a  logical  "chain  of  events". 

2.  It  should  allow  the  investigator  to  infer  differing  influences  on  these  events. 

3  It  should  prompt  the  investigator  to  seek  evidence  supporting  the  "ends"  of  these 
chains  by  continually  researching  the  simple  question  "why?"  using  logical 
deduction. 

4.  It  should  allow  the  AMB  to  "test"  various  scenarios  using  logical  abduction. 

5.  It  should  provide  a  useful  interaction  with  the  investigator  to  "visualize"  the 
mishap. 

When  we  speak  of  a  logical  chain  of  events  in  the  first  point,  we  refer  to  a  logical 
placement  of  causal  elements  rather  than  a  temporal  one.  The  temporal  chain  of  events 
focuses  on  the  order  of  events  rather  than  the  reason  for  their  occurrence.  Using  a  logical 
chain  of  events,  often  a  temporal  order  occurs,  but  the  reasoning  is  more  organized.  For 
example,  an  investigator  in  our  "toy"  mishap  would  continue  to  ask  why  an  event  occurred 
until  he  produced  evidence  and  then  would  ask  the  same  question  again.  The  end  result  of 
deliberation  is  a  series  or  a  set  of  statements  about  the  mishap,  the  statements  are  the 
result  of  dialog  among  the  members  of  an  Aviation  Mishap  Board.  The  following  is  a 
sample  logical  dialog  which  might  occur  during  a  mishap  board  deliberation: 

Why  did  the  mishap  occur?  Because  the  gear  was  up.  This  is 
supported  by  the  wreckage  photographs. 

Why  was  the  gear  up?  We  think  it  is  because  a  microswitch  failed. 

This  is  supported  by  a  wreckage  photograph  which  shows  the  switch  in  the 
open  position. 
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Why  did  the  switch  fail?  We  suspect  that  the  switch  failed  because  of 
corrosion  we  observed  on  the  switch.  This  is  supported  by  the  results  of  an 
engineering  investigation  stating  that  there  was  corrosion  on  the  switch. 

Why  was  there  corrosion  on  the  switch?  There  is  a  possibility  that 
the  switch  was  poorly  manufactured,  but  there  is  no  evidence  to  support 
this  (or  there  might  be  evidence  to  refute  this). 

Why  was  there  corrosion  on  the  switch?  We  think  that  the  aircraft 
was  improperly  hangared  and  corrosion  resulted.  This  is  supported  by 
maintenance  records  that  reflected  a  violation  of  hangaring  regulations. 

Why  were  the  regulations  not  followed?  We  think  poor  supervision 
is  the  result  of  the  improper  hangering  and  this  is  supported  by  maintenance 
records. 


The  above  discussion  follows  the  model  suggested  at  the  Aviation  Safety  School. 
This  logical  connecting  of  true  statements  forces  the  investigator  to  examine  each  scenario 
in  a  detailed  manner,  and  supported  arguments  become  the  basis  for  the  continuation  of 
the  logical  chain  and  investigation.  The  difficulty  with  the  logic,  however,  lies  in  the 
complexity  of  naval  mishaps.  Mishaps  occur  with  varying  amounts  of  evidence  and  AMBs 
must  consider  numerous  scenarios.  An  automated  system  supporting  this  type  of  logical 
process  serves  to  record  and  document  the  reasoning  process  used  during  an  AMB 
deliberation  session  and  also  serves  to  export  the  results  of  the  deliberation  directly  into 
the  final  Mishap  Investigation  Report  product. 

B.  THE  AMB  DELIBERATION  MODEL 

We  seek  to  automate  our  version  of  the  Safety  School  model  by  formalizing  the 
model  and  providing  examples  of  research  which  supports  the  use  of  such  a  type  of 
reasoning  in  modem  decision  theory.  The  type  of  diagramming  used  by  Maj.  Hazard  is 
not  uncommon  to  professional  disciplines  and  is  a  type  of  human  cognition  known  as 
"cognitive  mapping"  [Eden,  1988],[Duncan  and  Paradice,1992],  Cognitive  mapping  is 
broadly  applied  to  many  different  disciplines  but  in  this  case  refers  to  the  "representation 
perceived  by  an  human  being  to  exist  in  a  visible  or  conceptual  world"  [Zhang,  1994], 


31 


[Axelrod,  1976],  In  Mishap  investigation,  the  problem  space  is  the  entire  mishap  event 
consisting  of  a  set  of  evidences  and  causes.  Ultimately,  the  cognitive  map  will  look  much 
like  Maj.  Hazards  diagram,  but  we  provide  a  context  in  which  we  can  apply  formal  logic 
and  Artificial  Intelligence  methodology. 

Academicians  in  all  fields  have  recognized  the  importance  of  cognitive  mapping  for 
almost  a  century,  and  recently  it  is  becoming  more  important  as  computer  graphics  and 
Artificial  Intelligence  provide  a  means  to  manipulate  the  data  in  a  cognitive  map  [Axelrod, 
1976],  Not  only  can  we  reproduce  the  graphical  representation  of  a  mishap  investigation 
cognitive  map,  but  we  can  potentially  automate  the  entire  process.  With  enough  data  and 
tools  such  as  neural  networks,  we  can  envision  systems  which  analyze  mishaps  and 
determine  the  most  likely  causes  independent  of  human  decision  processes.  Although 
these  capabilities  exist,  the  practical  and  political  implications  of  a  system  which  excludes 
human  reasoning  would  make  implementation  impractical  in  the  current  aviation  safety 
environment.  We  propose  to  find  "middle  ground"  between  the  blackboard  method  of 
cognitive  mapping  and  the  total  reliance  on  computer  technology  in  the  investigation 
process  with  a  system  which  allows  the  user  to  reason  using  the  computer  as  a  guide  and 
administrator. 

When  visualizing  the  mishap  event  in  the  manner  taught  by  the  Aviation  Safety 
School,  we  create  a  cognitive  map.  The  effectiveness  of  the  cognitive  map  concept  is 
proven  in  numerous  artificial  intelligence  applications  and  can  serve  as  a  basis  for  model 
development.  The  importance  of  cognitive  mapping  is  illustrated  by  a  study  conducted  by 
Rook  and  Donnell  which  suggests  that  the  most  powerful  explanation  format  in  expert 
systems  is  the  graphic-  based  inference  explanations  based  on  existing  user  problem  spaces 
[Rook  and  Donnell,  1993],  In  our  context,  the  existence  of  visual  models  such  as  the  one 
developed  by  Hazard  provide  an  cognitive  map  which  we  should  seek  to  support  in  the 
graphical  context.  We  believe  it  is  reasonable  to  assume  that  a  cognitive  map  of  the 
mishap  problem  space  is  a  common  visualization  in  mishap  investigation  (although  we  can 
only  informally  verify  this)  among  investigators.  Although  we  cannot  assume  that  a 
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specific  type  of  cognitive  map  will  be  perfectly  understood  by  an  AMB,  the  representation 
presented  at  the  Aviation  Safety  School  provides  a  good  basis.  In  designing  the  model 
and  the  interface,  we  should  ensure  that  the  interface  communicates  the  graphical  problem 
space  and  the  textual  rule  based  problem  space  to  the  user  to  elicit  the  greatest  user/ 
interaction  performance  as  Rook  and  Donnell  suggest. 

In  order  to  formalize  the  Deliberation  Model,  we  apply  the  cognitive  mapping 
concepts  to  a  formal  knowledge  representation  scheme.  The  concepts  of  semantic 
networks  in  artificial  intelligence  combine  the  use  of  textual,  graphical  and  visual 
representations.  In  using  a  semantic  network  construct,  we  combine  the  idea  of  cognitive 
mapping  with  an  artificial  intelligence  heuristic  which  we  can  easily  formalize.  The 
original  development  of  semantic  networks  was  defined  by  Quillan  and  utilizes  a  set  of 
nodes  and  arcs  or  edges  to  represent  the  problem  space  [Quillan,  1968],  The  significance 
of  the  nodes  and  arcs  vary  with  the  goal  of  the  model,  but  the  use  of  semantic  networks  is 
widespread.  Quillan's  original  heuristic,  for  example,  defined  the  English  language 
through  detailed  definitions  of  nodes  and  arcs.  Another  type  of  network  was  developed 
by  Reiger  [Reiger,  C.,  and  M.  Grinberg,  1977],  and  uses  nodes  and  arcs  to  define  causal 
relationships.  Reiger' s  causal  networks  facilitate  descriptions  of  such  things  as  a  the 
operation  of  a  reverse-  trap  toilet  [Gonzalez  and  Denkel,  1993],  Semantic  networks 
provide  a  great  deal  of  flexibility  in  describing  a  problem  space,  and  facilitate  reasoning 
about  the  problem.  The  semantic  network  we  present  is  an  extension  of  Major  Hazard's 
work  and  allows  us  to  take  advantage  of  an  easily  understood  problem  space. 

1.  Model  Description 

We  describe  our  model  formally  in  the  context  of  a  directed  network  composed  of 
the  elements  mentioned  in  the  paragraph  above.  This  semantic  network  is  "directed" 
because  it  defines  relationships  from  a  "root"  probable  cause  or  evidence  to  a  "leaf' 
probable  cause  or  evidence.  We  clarify  the  definitions  of  these  terms  below.  Figures  4-2 
and  4-3  illustrate  examples  of  the  network,  using  our  previously  described  toy  mishap. 
Figure  4-2  is  a  branch  of  our  semantic  network,  indicating  its  basic  components.  Similar 
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Figure  4-2  Deliberation  Model  Branch 

to  Major  Hazard's  model,  the  network  expands  outward  with  the  nodes  at  the  beginning  of 
the  arcs  or  arrows  representing  the  more  basic  or  "roots"  of  the  mishap  while  the  nodes  at 
the  outermost  limits  (or  the  "leaves")  represent  the  ends  of  the  chains  of  events.  Thus  we 
may  say  that  a  unique  chain  of  events  or  a  scenario  is  defined  by  one  of  these  outermost 
nodes.  In  our  semantic  network,  evidence  is  a  unit  of  supporting  information  linked  by 
two  causes.  We  contend  that  a  cause  is  the  result  of  another  cause  and  this  relationship  is 
supported  by  evidence.  In  deliberation,  the  AMB  suggests  causes  until  a  reasonable  cause 
cannot  be  found.  The  set  of  resulting,  connected  causes  is  a  chain  of  events.  We  also 
refer  to  a  unique  chain  of  events  as  a  scenario. 

In  constructing  the  network  from  the  perspective  of  the  AMB,  we  recognize  that 
the  model  can  be  used  to  apply  "abductive"  logic  as  well  as  deductive  logic.  Abduction 
allows  the  board  to  propose  a  scenario  without  evidence,  effectively  leaving  these  nodes 
blank.  If  the  board  uses  deductive  reasoning,  it  proposes  a  cause  factor  based  on  the 
existence  of  an  evidence  element,  in  effect  the  network  which  applies  deductive  logic 
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Figure  4-3  Mishap  Deliberation  Model 

contains  nodes  which  contain  evidence.  As  with  the  strategy  described  by  Hazard,  the 
model  should  lead  the  AMB  to  ask  the  question  "why?"  in  either  case,  testing  various 
scenarios  and  then  looking  for  evidence  to  support  them  if  the  evidence  does  not  exist.  If 
the  board  decides  to  proceed  with  a  given  chain  of  events  such  as  the  one  represented  in 
Figure  4-2,  then  they  effectively  populate  the  nodes  with  supporting  evidence;  any  node 
that  cannot  be  filled  brings  the  entire  chain  of  events  into  question. 

Figure  4-3  is  the  full  conceptual  development  of  our  semantic  network  model. 
This  graphical  representation  is  the  development  of  the  cognitive  map  taught  at  the 
Aviation  Safety  School,  here  we  present  it  as  a  semantic  model  which  we  can  more  easily 
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formalize.  Figure  4-3  is  merely  numerous  branches  or  scenarios  joined  together  to 
represent  the  entire  problem  space,  or  the  entire  mishap.  As  discussed  in  figure  4-2,  each 
node  (labeled  "Ex")  represents  a  piece  of  evidence  and  each  arc  (labeled  "Cx")  represents 
a  cause.  The  dotted  lines  circle  unique  scenarios,  and  although  only  three  scenarios  are 
identified,  there  are  nine  different  scenarios  represented  here.  This  semantic 
representation  is  the  ideal  graphical  presentation  for  an  implementation.  It  combines  a 
common  cognitive  map  with  the  semantic  network  construct  which  is  a  common  artificial 
intelligence  developmental  tool,  and  lends  itself  to  the  textual  development  of  the  model 
through  predicate  logic  we  discuss  below. 

Although  the  semantic  network  directly  relates  to  the  investigators  perceived 
cognitive  map  of  the  mishap,  it  does  not  directly  aid  our  goal  of  the  automation  of  the 
deliberation  process.  The  network  allows  us  to  represent  knowledge  about  a  mishap 
graphically,  but  in  order  to  automate  the  deliberation  process  we  need  another  vehicle 
which  allows  us  to  generate  a  computer  based  system.  In  procedural  language  coding 
such  as  Pascal  or  Ada,  we  can  use  a  type  of  "psuedo  code"  which  attempts  to  make  the 
task  readable  as  a  sentence  or  a  statement  to  be  translated  to  code.  In  artificial 
intelligence,  a  common  approach  to  describing  statements  which  can  be  represented  by 
networks  is  predicate  logic  [Rowe,  1988], 

Predicate  logic  allows  us  to  formalize  the  relationships  in  our  network  and  describe 
the  assertions  made  during  a  deliberation  about  a  mishap.  Predicate  logic,  according  to 
Gonzalez  and  Dankel,  is  based  on  the  premise  that  sentences  express  relationships 
between  objects ;  in  our  case  these  objects  are  evidences  and  causes.  The  result  or  the 
application  of  predicate  logic  is  the  construction  of  "predicates"  or  predicate  clauses  which 
express  the  relationship  between  certain  terms.  The  two  basic  predicates  we  develop  are 
the  "evidence"  predicate  and  the  "probable  cause"  predicate.  These  predicates  define  the 
relationships  between  the  terms  or  objects  in  our  model  which  we  define  as  "cause 
factors”  and  "evidentiary  exhibits".  We  describe  these  terms  in  detail  below. 
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a.  Evidentiary  Exhibits 

In  the  earliest  stages  of  a  mishap,  the  investigative  team  must  begin  with 
the  "raw  data"  or  the  evidentiary  exhibits.  Each  exhibit  is  unique  and  may  be  in  the  form 
of  a  report,  an  interview,  a  photograph  or  even  an  physical  piece  of  an  aircraft.  This  is  the 
mishap  information  in  its  most  granular  form.  In  our  network,  the  evidentiary  exhibit  is 
the  information  which  is  contained  in  a  node.  As  we  noted  earlier,  the  model  may  or  may 
not  contain  evidentiary  exhibits,  depending  on  the  progress  of  the  deliberation.  An 
evidentiary  exhibit  is  one  of  the  items  or  objects  which  our  predicate  treats. 

b.  Cause  Factors 

In  the  act  of  deliberating  a  mishap,  the  AMB  will  suggest  a  set  of  cause 
factors.  A  cause  factor  may  or  may  not  be  based  on  evidence,  but  it  is  important  the 
model  support  both  abductive  and  deductive  logical  processes.  To  construct  a  set  of 
cause  factors,  the  board  deliberates,  and  in  deliberation  the  board  will  suggest  a  "root" 
cause  factor  and  proceed  to  suggest  a  set  of  cause  factors  representing  a  chain  of  events. 
In  our  network  representation,  they  would  be  proceeding  outward  away  from  the  root  and 
toward  the  ultimate  leaf  in  a  scenario,  the  cause  factors  are  the  arcs  in  the  network  and 
they  establish  a  connection  to  a  node.  We  might  say  that  a  node  (evidentiary  exhibit) 
supports  the  preceding  cause  factor  was  caused  by  the  following  cause  factor.  Referring 
to  Figure  4-2,  for  example,  we  can  say  that  the  information  contained  in  photo  2  was 
caused  by  the  cause  factor  failed  microswitch,  and  this  failed  microswitch  (supported  by 
the  evidentiary  exhibit  photo  2)  was  caused  by  corrosion.  The  logical  dialog  we  review  in 
Section  A  of  this  chapter  is  an  example  of  the  process  which  produces  cause  factors.  The 
cause  factor,  like  the  evidentiary  exhibit  is  the  other  basic  element  in  our  predicate 
development. 

c  Probable  Causes 

In  defining  a  probable  cause,  we  are  expressing  a  relationship  between 
cause  factors.  A  probable  cause  is  not  physically  represented  in  our  network,  it  is  rather 
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the  basic  relationship  between  cause  factors.  The  distinction  between  a  cause  factor  and 
the  probable  cause  factor  is  simple:  The  probable  cause  predicate: 
probable-cause  ( vause -factor A ,  cause-factor)”  states  that  "the  probable  cause  of  cause 
factor  A  is  cause  factor  B  .  Referring  back  to  our  network,  we  could  assert  an  instance 
as  probable-cause(failed-microswitch,  corrosion)  ,  representing  the  sentence  "the 
probable  cause  of  the  failed  microswitch  is  corrosion.  A  set  of  these  probable  cause 
relationships  and /  or  a  set  of  evidence  relationships  (discussed  in  the  next  section) 
compose  our  network. 

Our  network  model  implies  a  "transitive"  relationship,  in  other  words  if  a 
probable  cause  relationship  states  that  the  probable  cause  of  cause  factor  A  is  cause  factor 
B,  then  we  continue  the  deliberation  by  suggesting  a  cause  factor  which  caused  cause 
factor  B.  If  we  suggest  that  there  is  an  additional  cause  factor,  C  which  might  have 
caused  B,  then  we  create  another  probable  cause  entity  which  connects  B  and  C. 
Transitivity  allows  us  to  say  that  if  A  caused  B  and  B  caused  C,  then  C  is  also  related  to  A 
as  a  cause  factor.  This  transitivity  property  allows  us  to  construct  a  chain  of  events.  We 
apply  this  transitivity  property  by  imposing  some  limitations  on  the  construction  of  our 
predicates.  If,  for  example  we  have  a  chain  of  events  or  scenario  consisting  of  cause 
factors  A,  B,  C  and  D  in  a  scenario,  then  probable  cause  predicates  would  take  the 
following  form: 

probable-cause(cause-factor  A,  cause-factor  B), 
probable-cause(cause-factor  B,  cause-factor  C), 
probable-cause(cause-factor  C,  cause-factor  D). 

The  predicates  above  "chain"  or  connect  our  cause  factors  transitively  by  repeating  the 
second  cause  factor  as  the  first  cause  factor  in  the  next  clause.  Our  implementation 
depends  on  this  type  of  relationship  to  ensure  transitivity. 

<L  Evidence 

Evidence,  like  probable  cause,  describes  a  relationship.  This  relationship 
adds  an  evidentiary  exhibit  to  a  probable  cause  relationship  and  thus  allow  the  AMB  to 
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support  the  given  probable  cause  relationship.  If  we  apply  similar  predicate  notation  to 
this  relationship  we  can  say  "evidence(cause  factor  A,  cause  factor  B,  exhibit  C)" .  We 
read  this  as  "the  cause  factor  A  was  caused  by  cause  factor  B  and  is  supported  by 
evidentiary  exhibit  C" .  We  impose  transitivity  on  the  predicates  in  the  same  manner  as  we 
do  with  cause  factors,  only  we  attach  the  evidence  element  to  the  predicate. 

e.  Chain  of  Events 

A  chain  of  events  is  a  set  of  either  probable  cause  entities  or  evidence 
entities.  The  chain  of  events  is  defined  by  the  transitive  property  we  describe  above  and  is 
composed  of  a  "root"  node  and  a  "leaf'  node.  In  the  network  in  figure  4-3  we  have  a  set 
of  cause  factors,  and  a  set  of  evidentiary  exhibits.  The  nodes  represent  the  evidentiary 
exhibits  and  the  arcs  or  arrows  represent  the  cause  factors.  Each  discrete  path  in  this 
model  represents  a  chain  of  events. 

Ultimately,  the  AMB  must  support  any  given  scenario  with  evidence,  and  thus  the 
evidence  predicate  we  propose  ultimately  describes  all  scenarios  in  the  problem  space. 
Although  Hazard's  model  seems  to  deal  with  those  scenarios  we  might  call  true,  the  board 
may  also  want  to  support  arguments  that  are  not  true  in  order  to  document  reasoning. 
They  might  need  to  support  an  argument  against  some  suggested  scenarios  to  disprove 
unsupported  hearsay  or  illustrate  the  completeness  of  their  investigation.  OPNAVINST 
3750. 6Q  requires  the  AMB  to  document  this  logic  in  the  final  mishap  report  to  refute 
arguments  which  might  be  strongly  implied  but  not  supported  by  evidence.  Paragraph  607 
of  the  instruction  describes  how  the  mishap  board  "rejects"  plausible  scenarios  in  the  text 
of  the  message  that  the  board  considers  "too  remote  in  probability". 

We  now  continue  with  the  implementation  of  the  model  by  converting  our 
predicate  statements  to  Prolog  code.  Since  Prolog  is  based  on  predicate  logic,  this  task  is 
not  difficult  and  as  we  demonstrate,  our  predicates  become  the  data  elements  which 
populate  a  Prolog  database. 
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2.  The  Deliberation  Engine 

We  pursue  the  basic  implementation  of  the  model  in  the  Prolog  computer 
language.  The  "basic"  implementation  is  the  reasoning  engine  described  by  the  network 
model  in  the  previous  section  and  does  not  include  the  graphical  interface  which  we 
implement  in  another  context  later  in  this  chapter.  Prolog  was  developed  in  the  late 
1970s  and  stands  for  PROgramming  in  LOGic  and  is  based  on  predicate  logic.  It  provides 
some  distinct  advantages  over  procedural  languages  when  implementing  problems  that 
involve  reasoning.  Prolog  provides  mechanisms  which  "backtrack"  rather  than  querying 
databases  when  attempting  to  satisfy  a  rule.  The  alternative  to  Prolog  queries  in 
procedural  languages  such  as  Pascal  when  trying  to  solve  problems  similar  to  the  mishap 
deliberation  would  be  numerous  if-then  constructs  or  a  complicated  database  structure  of 
linked  lists.  Prolog  allows  developers  to  directly  test  the  truth  of  a  query  based  on  a  set  of 
predefined  rules.  In  addition,  the  structure  of  the  database  and  the  rules  are  related  to 
predicate  calculus  and  developers  can  apply  formal  logic  to  programming  without  having 
to  translate  logic  to  a  particular  language  procedure. 

A  Prolog  program  consists  of  three  elements  according  to  Clocksin  and  Mellish: 

♦  Facts  about  objects  and  their  relationships, 

♦  Rules  about  objects  and  their  relationships, 

♦  Questions  or  queries  about  objects  and  their  relationships  [Clocksin  and  Mellish, 
1984], 

In  keeping  with  our  original  example,  we  begin  this  discussion  by  presenting  the 
Prolog  database  of  the  example  presented  in  chapter  2,  or  the  "facts"  as  described  by 
Clocksin  and  Mellish.  In  our  model,  the  relationship  predicates  we  presented  earlier  define 
the  facts  that  will  populate  the  prolog  database.  The  Prolog  computer  language  is  based 
on  predicate  statements  similar  to  the  examples  we  presented.  Appendix  C  provides  the 
database  populated  with  information  from  our  example.  Two  typical  examples  of  this 
code  are  as  follows: 

prob_cause(aircraft_mishap,gear_not_down). 

evidence(aircraft_mishap,gear_not_down,wreckage_inspection). 
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The  reader  will  recognize  the  relation  ship  between  prolog  code  and  predicate 
logic:  The  code  above  is  a  reproduction  of  the  predicates  we  developed  applied  to  Prolog. 
This  example  and  the  complete  listing  in  Appendix  C  are  examples  of  a  list  of  the  predicate 
relationships.  In  Prolog,  the  database  is  composed  of  the  set  of  assertions  about  the  data, 
our  database  is  composed  of  evidence  and  prob_cause  predicates.  The  user  of  a  common 
Prolog  interpreter  such  as  the  Quintus  system  can  either  enter  each  of  the  individual 
predicates  into  an  interpreter,  or  the  user  can  create  a  file  containing  the  list  of  predicates 
and  have  these  facts  loaded  in  during  the  interpreter  initialization.  Once  the  facts  are  in 
the  Prolog  database,  we  can  query  in  a  number  of  ways.  Prolog  allows  us  to  simply 
request  the  contents  of  the  database,  or  we  can  develop  a  set  of  rules  which  define 
relationships  between  predicates.  We  reproduce  our  model  by  writing  a  set  of  Prolog 
rules  presented  in  Appendix  C,  Section  B.  These  rules  allow  the  user  to  query  the 
database  for  sets  of  predicates  describing  scenarios  and  related  evidence.  Again,  the  user 
can  either  enter  these  rules  into  the  terminal  or  use  the  Prolog  "consult"  routine  to 
automatically  load  the  rules  into  the  system  upon  initialization.  The  code  includes 
comments  which  explain  much  of  the  syntax.  The  reader  will  find  consistency  between  the 
Prolog  rules  in  the  Appendix  and  the  development  of  the  model  in  the  previous  section. 
It  is  not  the  purpose  of  this  chapter  to  provide  an  instruction  in  Prolog  syntax,  thus  we 
provide  basic  descriptions  of  the  code  in  the  comments  of  the  program  for  easier 
reference.  The  functionality  of  the  "rules"  of  this  program  provide  the  user  with  a  means 
to: 


1.  Query  the  contents  of  a  scenario  chain. 

2.  Query  the  final  link  in  a  scenario  chain  and  thus  determine  the  root  cause. 

3 .  Query  any  fact  in  the  database  and  examine  the  chain  which  proceeds  from  it. 

4.  Retrieve  an  explanation  for  a  completed  and  "supported"  chain  of  events, 
including  the  evidence  associated  with  probable  causes. 
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Appendix  C,  Section  C  provides  a  scripted  query  result  and  illustrates  how  a  set 
of  rules  we  define  in  Prolog  function  once  loaded  into  the  Prolog  interpreter.  The  first 
query,  "prob_cause(X,Y)"  requests  the  contents  of  the  "prob_cause"  database  .  As 
Appendix  C  indicates,  the  query  simply  returns  a  listing  of  prob  cause  predicates  in  the 
database. 

The  type  of  query  initiated  above  could  also  ask  for  the  second  half  of  a  pair  of 
causes.  For  example,  if  we  wanted  to  know  what  cause  was  paired  with  "improper 
hangering"  we  would  simply  enter  "prob_cause(improper_hangering,  Y)"  and  the  database 
would  return  "poor_supervision".  The  next  query  utilizes  a  "scenario  rule"  defined  by 
the  code  in  Appendix  C,  Section  B.  This  rule  is  implemented  by  three  Prolog  statements  , 
"scenario",  "scenariochain"  and  "scenario  chain  it".  These  three  statements  allow  the 
user  to  query  a  list  of  cause  factors  which  compose  a  scenario  chain.  Section  C  of 
Appendix  C  contains  a  run  of  this  type  of  query  by  requesting  all  scenarios  in  the  database 
calling  the  procedures  with  the  statement  "scenario  _chain(X,Y)".  The  script  thus 
contains  all  of  the  scenarios  in  the  database. 

Each  one  of  the  "X”  values  in  the  above  query  holds  the  value  of  a  cause  factor, 
and  the  "Y"  values  contain  the  list  of  the  causes  which  proceed  from  that  cause  factor. 
The  reader  should  note  that  these  queries  are  not  based  on  evidence,  thus  the  Prolog  rules 
implemented  here  satisfy  the  abductive  reasoning  requirement  mentioned  earlier  by 
allowing  the  user  to  logically  "test"  scenarios  without  providing  supporting  evidence.  The 
script  below  continues  the  example  run  by  illustrating  how  the  user  can  request  the  cause 
factors  emanating  from  a  particular  cause  factor  which  begins  the  "chain".  By  entering 
"scenario_chain(poor_training,Y). ",  Prolog  returns  the  list  containing  the  chain  or  cause 
factors  particular  to  "poor  training".  This  type  of  query  is  reproduced  again  with  the 
second  query. 

scenario_chain(poor_training,Y). 

Y  =  [crew_uncoordinated,no_coord_training,no_command_support] ; 

No 

scenario_chain(handle_malfunctioned,Y). 
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Y  =  [improper_maintenance,omitted_step,poorly_written_handbook, 

missing_page] ; 

We  are  able  to  ask  the  database  the  contents  of  a  scenario  relating  to  any  cause 
factor.  If  a  particular  cause  factor  becomes  the  cause  of  more  than  one  scenario,  then  the 
Prolog  interpreter  would  simply  list  these  additional  scenarios.  In  our  example  above, 
however,  both  "poor_training"  and  "handle  malfimctioned"  result  in  only  one  chain  of 
events  each. 

The  final  Prolog  Rule  allows  the  user  to  query  an  "explanation"  to  a  tested  chain  of 
events.  The  "explain  scenario"  rule  applies  our  second  logical  rule  which  attaches 
evidentiary  exhibits  to  the  cause  factors.  In  querying  a  root  and  a  general  cause,  the  user 
can  determine  if  he  has  evidence  to  support  the  scenario.  Thus  the  query  only  returns 
those  scenarios  supported  by  evidence.  The  following  script  illustrates  a  query  request  to 
support  the  scenario  which  was  caused  by  a  poorly  written  maintenance  handbook: 

explain_scenario(gear_not_down,  poorly_written_handbook,  Explain). 

Explain  =  [gear_not_down,'was  caused  by',handle_malfunctioned,’and  is  supported 
by\wreckageJnspection,...,handle_malfunctioned,'was  caused  by',improper_maintenance,’and  is 
supported  by,,recordsJnsp,...,improper_maintenance,'was  caused  by',omitted_step,'and  is 
supported  by’, handbook, ...,omitted_step,’was  caused  by',poorly_written_handbook,,and  is 
supported  by',expert_interview,...] ; 

If  the  scenario  above  contained  causes  that  did  not  contain  evidence,  then  the 
Prolog  interpreter  would  return  "No"  indicating  that  the  database  did  not  satisfy  the  rule. 
The  following  is  another  example  of  the  above  type  of  query  which  examines  a  scenario  in 
"mid-  chain"  to  illustrate  the  a  branch  of  a  scenario  which  composes  a  separate  scenario: 


explain_scenario(no_waming_hom,  corrosion,  Explanation). 
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Explanation  =  [no_waming_hom,'was  caused  by',malfunctioning_switch,’and  is 
supported  by',wreckage_examination,...,malfunctioning_switch,'was  caused  by', corrosion, 'and  is 
supported  by’,wreckage_examination,...] ; 

The  Prolog  implementation  presented  in  this  section  discusses  only  the  rules  and 
the  logical  model  implementation,  or  the  reasoning  "engine".  The  prototype 
implementation  however,  is  incomplete  without  the  addition  of  a  user  interface.  Although 
we  present  an  implementation  of  the  logic  in  the  form  of  a  Prolog  program,  the  user 
interface  completes  the  application  of  logic  described  by  our  model.  The  interface  must 
allow  the  user  to  communicate  queries  to  the  database  and  preserve  the  process  for 
deliberation  described  by  our  logical  model.  The  next  section  provides  an  example  of  such 
an  interface,  the  reader  may  note  that  this  approach  and  the  Prolog  code  generated  in 
Appendix  C  support  an  stand-  alone  system,  but  simple  modifications  would  allow 
developers  to  adapt  the  same  code  to  support  the  client/  server  approach  described  in 
Chapter  II. 

3.  Interface  Goals,  User  Run-Time  Routines 

The  importance  of  the  user  interface  in  the  deliberation  application  cannot  be 
overlooked.  Even  if  the  logic  we  present  for  the  model  is  sound  and  useful  for 
implementation,  the  application  will  be  useless  if  the  user  interface  is  not  carefully 
designed.  When  we  describe  the  interface,  we  are  referring  to  the  interaction  between  the 
user  and  the  Prolog  rules  presented  in  the  previous  section.  The  method  for  composing 
the  predicate  relationships  that  compose  the  "facts"  in  the  database  should  be  designed 
into  the  user  interface  so  the  user  understands  the  reasoning  process. 

The  "strategy"  we  mention  as  a  goal  of  the  deliberation  application  in  the  opening 
paragraphs  of  this  chapter  should  be  implemented  as  an  interactive  element  of  the  user 
interface.  The  core  of  the  application,  the  deliberation  model  written  in  Prolog,  should  be 
supported  by  a  user-  computer  interaction  which  provides  correctly  formatted  data  to  the 
Prolog  interpreter  or  engine.  This  interaction  should  make  clear  the  rules  used  in  the 
model  and  present  a  graphical  interpretation  similar  to  the  semantic  model  on  which  our 
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Prolog  model  is  based.  A  successful  interface  should  not  only  allow  the  user  access  to  the 
database,  but  it  should  also  communicate  the  underlying  logic  of  the  model  to  facilitate 
accurate  reasoning.  One  of  the  goals  of  the  interface  should  be  to  ensure  the  user  has 
access  to  the  decision  making  process  as  Rook  and  Donnell  suggest.  This  type  of 
interaction  will  extract  the  greatest  user  performance  levels  which  in  our  context  is 
accurate  and  timely  mishap  investigation  [Rook  and  Donnell,  1993],  In  addition,  the 
interface  should  organize  the  mental  model  or  cognitive  map  of  the  user  and  enable  the 
AMB  to  revisit  and  reconstruct  the  cognitive  maps  of  previous  deliberations  when  the 
investigation  occurs  over  a  period  of  time.  This  recording  of  the  deliberation  process  is  an 
essential  functionality:  Without  it  the  AMB  might  re-deliberate  the  mishap  problem  each 
time  it  reconvenes,  wasting  time  and  introducing  inaccuracies.  Finally,  our  interface 
should  provide  easy  access  to  a  database  server  and  other  applications  of  the  system  and 
enable  the  user  to  produce  the  output,  the  final  mishap  message. 

4.  Screen  Prototype  Presentation 

Version  1.0B  of  the  "Mishap  Expert"  is  a  prototype  used  to  demonstrate  the 
functionality  of  the  program  and  the  desired  user  inter  face  and  routines.  Version  1  OB  is 
not  a  client-  server  version,  and  the  database  is  maintained  entirely  by  the  Prolog 
interpreter.  The  Prolog  interpreter  is  a  basic  Edinburgh  syntax  interpreter  which  has 
limited  windows  API  (Application  Program  Interface)  capabilities;  serious  development 
of  this  application  will  require  a  full  API  enabled  interpreter  [See  SWI  reference  for 
interpreter  information].  The  interface  is  written  in  Borland's  Delphi,  and  the  application 
itself  is  non-proprietary  and  not  copyrighted.  At  the  writing  of  this  thesis,  a  team  of  Naval 
Postgraduate  School  students  is  developing  a  client/  server  version  (version  1.1B)  of  the 
entire  system  which  will  include  import  and  export  of  message  information  to  and  from 
this  application.  The  purpose  here  is  simply  to  present  a  basic  functional  interface  for  the 
Prolog  implementation. 

a.  Mishap  Expert,  version  LOB 
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Version  1.0B  is  a  "bare-bones"  prototype  of  the  deliberation  model 
presented  earlier  in  this  chapter.  The  purpose  of  presenting  this  basic  interface  is  to 
specify  and  demonstrate  the  advantages  of  an  effective  user  interface  for  the  Prolog 
reasoning  engine.  Thus  we  only  demonstrate  basic  capability  in  this  version  enabling  the 
user  to  perform  the  functions  performed  by  the  above  Prolog  code.  The  prototype  is 
written  in  Borland's  Delphi  using  the  Object  Pascal  language.  The  designed  format 


Figure  4-4  Version  1  .OB  Investigation  Screen 

includes  a  "Tabbed  Notebook"  format  similar  to  the  "Notebook"  application  designed  by 
LT  Hugh  Brian.  By  clicking  on  any  of  the  "Tabs"  located  at  the  top  of  the  page,  the  user 
may  navigate  through  the  application.  The  screen  in  figure  4-4  is  the  Investigation  screen. 
The  primary  purpose  of  this  screen  is  to  build  the  "prob_cause"  predicate  database  for  the 
Prolog  interpreter.  This  screen  is  also  designed  to  introduce  the  user  to  the  logic  of  the 
model  and  serve  as  a  tutor  in  the  investigative  logic  it  applies.  The  run-  time  routine  we 
apply  here  is  important  to  both  the  formatting  of  the  input  into  Prolog  code  and  to 
"educating"  the  user  about  the  reasoning  of  the  system . 
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First  the  user  is  prompted  to  enter  the  most  general  cause  of  the  mishap, 
after  the  initial  entiy  of  the  first  "cause  factor"  the  caption  over  the  top  entry  box  changes 
from  "Enter  the  Mishap  Description"  to  "Continue  by  selecting  an  event,  or  a  new  cause 
factor".  In  addition,  a  button  enabling  the  user  to  create  the  predicate  appears.  When  the 
user  enters  information  in  the  top  box,  two  events  occur.  First,  the  top  box  is  disabled  so 
that  the  user  is  forced  into  an  entry  into  the  second  box.  Second,  the  cursor  moves  to  the 
second  box  where  the  user  is  prompted  for  the  reason  for  the  occurrence  of  the  event 
appearing  in  the  upper  box.  In  this  manner,  the  application  prompts  the  user  for  the  next 
link  in  the  chain  of  events.  Once  the  user  clicks  on  the  "create"  button,  the  predicate  is 
added  to  the  list  and  the  application  makes  another  option  available  in  the  form  of  an  "End 
Scenario"  button. 

As  the  user  exits  the  lower  entry  box,  the  two  statements  are  formatted  and 
converted  to  Prolog  syntax  forming  the  prob  cause  predicate  which  is  appended  onto  the 
end  of  a  list  and  eventually  saved  to  a  text  file  to  be  loaded  into  the  interpreter  in  another 
application  function.  In  this  version  of  the  application,  the  formatted  statements  appear  in 
the  list  box  to  the  right  of  the  edit  boxes.  For  example,  if  the  user  entered  the  system  for 
the  first  time  and  entered  the  root  cause  as  "Gear  Not  Down"  and  either  exited  the  box  or 
clicked  on  "OK"  the  cursor  would  move  to  the  second  box.  When  the  user  enters  the 
second  box,  the  contents  of  the  first  box  dim,  and  that  box  becomes  read-  only.  When  the 
user  enters  another  cause  in  the  lower  box  and  exits,  the  Prolog  predicate  statement 
appears  in  the  list  box  to  the  right.  If  the  user  entered  "Malfunctioning  Handle"  in  the 
lower  box  and  exited  the  box,  the  system  would  format  the  pair  of  causes  and  transfer  the 
contents  of  the  lower  box  to  the  upper  box  prompting  the  user  to  enter  another  cause. 
This  function  logically  steps  the  user  through  the  scenario,  and  also  ensures  the  predicate 
arguments  are  identical  in  syntax.  This  matching  syntax  is  necessary  for  the  model  "rules" 
to  function  properly.  For  example,  the  deliberation  engine  will  relate  the  predicates 

prob_cause  (gear_not_down,  malfunctioning_handle) , 
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prob_cause  (malfunctioning_handle,  failed_microswitch 

together  only  when  it  recognizes  the  common  "malfunctioning  handle”  argument.  If  the 
application  does  not  force  this  type  of  formatting,  then  the  model  will  treat  each  differing 
entry  as  a  separate  cause  factor  and  unrelated  causal  pair. 

Version  1.  OB  is  a  single  session  version  with  no  database  capabilities.  Thus 
when  the  user  selects  the  "End  Scenario"  button,  the  upper  box  is  enabled  and  the  user  is 
able  to  begin  another  scenario  and  add  to  the  predicate  list.  Version  1 .  IB,  however  uses  a 
database  and  the  user  is  forced  into  selecting  an  existing  cause  factor  during  the 
deliberation  of  a  single  mishap,  and  prohibits  the  user  from  entering  a  new  cause  factor  in 
the  top  entry  box.  If  we  do  not  impose  this  limitation  on  the  user,  then  the  addition  of  a 
new  cause  factor  in  the  top  box  would  cause  the  Prolog  interpreter  to  treat  is  as  a  separate 
mishap,  because  it  would  not  be  related  to  any  other  existing  predicate  in  the  database. 

Clicking  on  the  "Evidence  Log"  tab  moves  the  user  to  the  evidence  log 
screen  presented  in  figure  4-4.  The  evidence  log  simply  allows  the  user  to  add,  modify  or 
delete  information  from  a  temporary  file  holding  evidence  information.  The  evidence  log 
provides  a  repository  for  evidence  if  the  user  chooses  not  to  begin  deliberation 
immediately,  this  function  is  purely  a  database  of  evidence  information.  Version  1.0B 
reproduces  the  list  of  evidence  in  the  Scenario  Reviewer  screen  to  build  the  evidence 
predicate  saved  in  the  "facts.pl"  file.  Evidence  is  important  to  the  application  when  the 
user  is  interested  in  viewing  the  textual  and  graphical  results  of  a  deliberation,  and  figure 
4-5  presents  the  "Scenario  Reviewer"  screen  which  constructs  the  Prolog  evidence 
predicates. 

The  Scenario  Reviewer  presents  the  user  with  the  list  of  predicates  built  in 
the  Investigation  screen  (in  the  left  box)  and  the  list  of  evidence  articles  entered  in  the 
Evidence  screen.  By  selecting  prob_cause  predicate  and  a  piece  of  evidence  and  clicking 
"Create",  the  user  supports  a  clause  "cause_factor2  occurred  as  a  result  of  cause  factorl" 
in  the  form  of  a  Prolog  predicate  with  a  piece  of  evidence  and  creates  the  evidence 
predicate.  If  for  example,  the  left  box  included  a  list  of  prob  cause  statements  including 
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the  predicate  prob_cause(gear_not_down,  malfunctioning  handle)  and  the  evidence  "photo 
1 "  then  the  user  could  select  both  of  these  items  and  then  click  "Create"  and  the  system 
would  build  the  predicate  evidence(gear_not_down,  manfunctioning_handle,  photo  1),  and 
add  it  to  the  "Evid.pl"  text  file  which  stores  the  predicates  to  load  into  the  Prolog 
interpreter.  This  functionality  allows  the  user  to  construct  the  predicates  necessary  to 
perform  the  queries  in  a  subsequent  screen.  By  selecting  the  View  Evidence  button,  he  is 
taken  to  a  screen  which  lists  the  contents  of  this  text  file. 

When  the  user  selects  the  "View  Scenarios"  button,  he  is  moved  to  a 
separate  application  screen  not  in  the  tabbed  notebook.  Including  the  view  function  in  the 
tabbed  notebook  might  tempt  the  user  to  view  a  the  results  of  a  query  before  the  file  has 
been  built.  The  View  Scenarios  screen  in  Figure  4-6  is  the  query  generator  for  the  Prolog 
engine.  The  view  button  opens  the  view  screen,  and  opens  and  initializes  the  Prolog 
interpreter.  By  "initializing"  we  mean  the  loading  of  the  existing  "factors.pl"  and  "evid.pl" 
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Scenario  Viewer 


Figure  4-6  Version  1  .OB  Scenario  Viewer  Screen 


files  into  the  interpreter  along  with  the  "rules.pl"  file  which  holds  the  prolog  rules 
supporting  our  model.  Ideally,  the  interpreter  would  be  opened  at  this  time  and  the 
application  and  the  interpreter  would  communicate  with  API  calls.  Due  to  the  limitations 
of  our  interpreter,  however,  we  must  rely  on  separate  initializations  for  each  button  query 
function,  returning  the  contents  of  "scripted"  files  recorded  by  the  common  Prolog 
predicate  "tell".  This  predicate  writes  the  results  of  a  query  to  a  text  file,  which  the 
interface  displays  back  to  the  user.  In  combination  with  the  use  of  a  custom  query  routine, 
we  can  attach  any  of  the  queries  mentioned  in  the  previous  section  to  a  separate  button 
which  initializes  the  interpreter,  loads  the  database,  performs  a  query  and  returns  a  value 
to  a  text  file  and  then  closes  the  interpreter.  Appendix  C,  Section  D  provides  an  example 
of  these  routines  along  with  the  initialization  file.  The  code  in  Appendix  C  is  re-applied  to 
each  query  generation  button  in  the  application,  customized  to  the  particular  query 
involved.  This  is  clearly  an  inefficient  method  only  implemented  here  to  demonstrate 
functionality;  a  better  solution  would  utilize  a  Prolog  interpreter  which  supports  direct 
communication  between  applications  such  as  OLE  (Object  Linking  and  Embedding)  or 
DDE  (Dynamic  Data  Exchange).  This  type  of  solution  would  increase  the  speed  and 
efficiency  of  the  system  above  the  prototype  implementation. 

The  view  screen  in  Figure  4-6  contains  four  choices.  The  user  may  view 
all  scenarios,  in  which  the  interpreter  executes  the  scenario(X,Y)  query  and  the  system 
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Figure  4-8  Version  1  .OB  Unsupported  Scenario  Screen 


returns  a  list  of  all  the  developed  scenarios  in  the  box  in  Figure  4-7.  If  the  user  desires  to 
view  a  scenario  beginning  with  a  particular  event,  he  moves  to  the  "unsupported  scenario" 
screen.  Figure  4-8,  and  selects  a  particular  prob  cause  pair.  The  "go"  button  will  execute 
the  query  instantiating  the  X  variable  to  the  first  argument  of  the  selected  prob_cause 
predicate.  For  example  if  the  user  wanted  to  query  the  prolog  database  about  the 
"handlemalfunctioned,  improper  maintenance  scenario  as  in  our  earlier  example,  he 
would  select  that  predicate  from  the  left  box  and  click  on  "go".  The  interpreter  would 
then  execute  a  scenario(handle_malfiinctioned,  Y)  query  and  return  the  same  list  we 
presented  in  the  earlier  section. 

The  explain  scenario  button  executes  and  displays  the  results  of  the 
explainscenario  query  described  earlier  in  this  chapter  in  Figure  4-9.  The  application 
presents  the  user  with  a  list  of  existing  scenario  causes  (the  results  of  the  scenario(X,Y) 
query)  and  the  user  selects  one  of  the  presented  scenarios.  The  application  takes  the  first 
and  the  last  arguments  and  forms  the  explain_scenario(X,Y,Z)  query.  For  example,  if  the 


Figure  4-9  Version  1  .OB  Explain  Scenario  Screen 
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user  selected  the  displayed  scenario  containing  gear_not_down  and 
poorly_written_handbook,  the  text  box  would  display  the  same  output  generated  in 
response  to  this  query  presented  in  the  previous  section. 


b.  Version  1.1B 

Version  1.1B  (currently  under  development)  implements  the  above 
application  with  a  Database  Management  System  provided  by  the  Borland  Delphi 
package.  The  local  database  will  enable  enhanced  functionality  in  the  application  and  will 
allow  the  system  to  export  information  to  the  server  in  the  architecture  described  in  the 
Chapter  III.  Version  1.1B  will  be  included  as  a  prototype  application  in  a  project 
delivered  to  NPS  faculty  in  partial  fulfillment  of  the  requirements  for  the  IS  4925  course  at 


Figure  4-10  Version  1.1B  Graphical  Presentation  Prototype 
the  Naval  Postgraduate  School. 

Version  l.IB  will  implement  the  graphical  description  of  the  model 
important  to  the  user  interface.  Figure  4-10  is  a  prototype  of  this  graphical  description 
of  a  chain  of  events  and  comes  close  to  the  semantic  model  description  of  our  deliberation 


model.  This  representation  allows  the  user  to  view  the  mishap  scenario  in  one  of  two 
contexts.  The  model  can  be  called  after  the  execution  of  a  scenario(X,Y)  query,  or  it  can 
contain  the  contents  of  an  explain_scenario(X,Y,Z)  query.  Since  version  1 .  IB  will  contain 
a  local  database  for  query  and  data  storage,  we  will  be  able  to  place  the  contents  of 
related  tables  in  the  fields  of  the  graphical  description,  and  perform  the  Prolog  queries  on 
database  pointers  rather  than  formatted  textual  descriptions.  When  the  user  desires  to 
view  a  scenario  in  this  screen,  he  will  see  the  probable  causes  (as  he  entered  them) 
displayed  above  the  arcs  in  the  diagram,  while  the  nodes  will  simply  display  the  word 
"evidence'1.  When  the  user  views  the  same  screen  returning  the  results  of  an 
"explain  scenairio "  type  query,  the  application  will  label  the  arcs  with  the  causes  and  fill  in 
the  nodes  with  a  single  word  description  of  the  evidence  explaining  the  adjacent  cause 
factors.  This  evidence  text  will  be  colored  and  will  serve  as  a  hypertext  link  to  the  field  in 
the  database  containing  the  detailed  description  of  that  particular  piece  of  evidence. 

In  addition  to  the  graphical  display  capability  described  by  Figure  4-10, 
version  1.1B  will  also  contain  the  necessary  "housekeeping"  capabilities  enabling  the  user 
to  maintain  the  database  containing  the  mishap  information.  The  Prolog  deliberation 
engine  code  will  not  require  revision  in  files  other  than  the  initialization  routines  included 
with  specific  queries.  The  use  of  the  database  will  bring  the  necessary  closure  to  the  entire 
application  by  allowing  the  user  to  export  the  results  of  the  AMB  deliberation. 

When  the  user  performs  the  explain  scenario  query,  the  application  will 
only  return  complete  chains  of  events  which  are  supported  by  evidence.  As  mentioned  in 
Chapter  II,  the  OPNAV  3750.6  instruction  requires  the  AMB  to  both  accept  and  reject 
scenarios  based  on  supporting  evidence.  Thus  in  this  context,  evidence  can  serve  to 
support  or  disprove  a  chain  of  events.  In  either  case,  the  chain  of  events  discussed  in  the 
message  must  be  supported  by  evidence  in  order  for  it  to  appear  in  the  message  as  an 
accepted  or  rejected  cause  factor.  The  MIR  generation  module  appends  the  deliberation 
information  to  the  initial  mishap  report  in  a  formalized  manner.  The  Mishap  Expert 
application  should  contain  export  the  evidence  descriptions  entered  in  the  original 
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evidence  log,  and  the  data  returned  by  the  "explain_scenario"  queries.  The  MIR 
generation  module  should  allow  the  user  to  choose  the  queries,  accept  or  reject  them 
based  on  the  content  of  the  evidence  and  proceed  with  the  remainder  of  the  final  mishap 
message. 
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V.  CONCLUSION 


This  thesis  outlined  the  development  and  implementation  of  a  decision  support 
system  for  Naval  Aviation  Mishap  investigation  and  reporting,  and  presented  the 
"deliberation  model"  for  mishap  investigation.  In  outlining  the  implementation,  we 
concentrated  on  the  model  for  deliberation  using  artificial  intelligence  methods  and  the 
Prolog  language.  Finally,  we  outlined  the  implementation  of  the  model  in  the  "Mishap 
Expert"  application.  At  the  writing  of  this  thesis,  the  development  of  version  1.  lb  of  the 
entire  support  system  was  ongoing,  and  completion  of  a  fully  functional  prototype  is 
expected  by  October  of  1995.  Version  1.0B  is  a  basic  implementation  of  the  Mishap 
Expert  application  only.  This  application  prototype  presents  the  Prolog  model  with  a 
very  basic  user  interface  which  demonstrates  desired  routines.  A  foil  implementation  of 
this  system  requires  significant  further  study  and  many  of  these  important  issues  are 
beyond  the  scope  of  this  thesis. 

A.  IMPLEMENTATION  ISSUES 

This  thesis  presents  a  largely  experimental  implementation  of  the  DSS  and  the 
deliberation  application.  The  full  implementation  of  a  similar  system  for  fleet  use  requires 
careful  study  and  consideration  of  such  issues  as  infrastructure  supporting  a  client/  server 
architecture  and  compatibility  with  different  platforms.  In  addition,  the  selection  of  the 
database  system  and  the  related  applications  (such  as  the  Prolog  interpreter)  require 
careful  attention.  An  informal  survey  of  aviation  squadrons  indicates  that  this 
infrastructure  does  not  exist  in  most  cases,  and  thus  the  client/  server  approach  is  presently 
infeasible.  We  suggest  that  the  most  practical  application  of  this  model  is  therefore  a 
single-platform  system  supported  by  a  database  as  described  in  Chapter  III. 

The  use  of  Prolog  and  Borland's  Delphi  in  this  prototype  should  not  suggest  that 
this  is  the  only  implementation  approach.  Developers  may  find  solutions  using  other 
languages  and  tools.  The  commercial  Prolog  market  continues  to  grow  and  at  this 
writing,  powerful  and  complete  graphical  Prolog  development  tools  are  appearing. 
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hopefully  future  development  of  this  model  will  result  in  an  single  application  providing 
reasoning  and  a  user  interface  rather  than  the  use  of  multiple  applications  demonstrated  in 
our  prototype. 

B.  QUESTIONS  FOR  FURTHER  STUDY 

The  obvious  subject  for  further  study  in  this  thesis  is  the  full  implementation  and 
testing  of  the  entire  Decision  Support  System.  As  mentioned  in  Chapter  IV,  this  research 
is  ongoing  and  will  be  completed  by  October  of  1995.  In  addition  to  the  implementation 
of  the  system,  we  suggest  further  questions  for  study: 

♦  The  implementation  and  testing  of  the  entire  decision  support  system. 

♦  An  examination  of  the  computing  infrastructure  necessary  to  support  such  a  system. 

♦  How  would  the  department  of  the  Navy  support  this  software  implementation? 

This  question  will  become  increasingly  important  as  end-  users  continue  to  develop 
useful  information  applications.  If  the  support  for  end-  user  applications  is  not 
specified,  users  might  become  dependent  on  an  application  with  no  recourse  when 
the  application  or  system  fails  or  requires  update.  In  applications  where  processes 
are  automated  such  as  the  message  generation  capabilities  of  our  system,  the 
absence  of  an  automated  system  might  paralyze  an  organization  that  forgets  how  to 
manually  execute  automated  processes.  This  question  is  particularly  important  to 
DoD  when  military  officers  develop  applications  and  subsequently  move  to  other 
assignments,  taking  the  "support"  for  an  application  with  them. 

♦  Additional  analysis  of  the  deliberation  model,  with  continued  discussions  with  the 
Aviation  Safety  School.  This  model  may  also  be  appropriate  for  entry  into  the 
OPNAVINST  3750.6Q  instruction  as  a  method  for  investigation. 

As  we  discussed  in  the  introduction  of  this  thesis,  we  presented  the  development  of 
the  administrative  system  architecture  to  the  end-user  developer  recognizing  the  growing 
trend  of  end-user  application  development  with  such  tools  as  Borland's  Delphi.  As  tools 
become  available  to  end-users  to  develop  applications  with  increasing  ease,  examinations 
of  processes  and  practices  such  as  the  mishap  deliberation  process  we  present  here  will 
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become  more  important.  The  "addiction"  to  the  power  of  Rapid  Application  Development 
(RAD)  tools  will  lead  to  an  explosion  of  applications  which  do  not  support  or  improve  a 
defined  process.  Thus  process  examination  in  application  development  will  become  more 
important  than  application  implementation. 

Our  discussion  directly  addressed  a  weakness  in  the  Naval  Aviation  Safety  mishap 
investigation  process.  Although  the  Aviation  Safety  School  at  the  Naval  Postgraduate 
School  informally  teaches  a  deliberation  methodology,  this  methodology  is  not  formalized 
in  the  directive  instruction,  OPNAVINST  3750.6Q.  In  suggesting  a  strategy  based  on  the 
teaching  methods  at  the  NPS  Safety  school,  we  provide  an  avenue  for  improved  mishap 
investigation  and  reporting  through  the  use  of  an  automated  "deliberation"  model.  In 
addition,  we  present  the  architecture  for  an  administrative  system  to  support  the  entire 
reporting  process. 

As  the  Navy  continues  to  downsize  and  conserve  resources,  the  preservation  of 
both  human  and  material  assets  in  naval  aviation  will  receive  greater  attention.  The 
thoughtful  examination  of  the  investigation  process  and  the  application  of  appropriate 
technology  can  enhance  and  improve  mishap  investigation  and  reporting.  By  supporting 
the  administrative  demands  of  an  investigation  and  providing  a  defined  process  for 
deliberation,  an  implementation  of  the  model  discussed  here  will  not  only  improve  the 
efficiency  of  the  investigation  process,  it  will  also  improve  the  quality  of  the  completed 
investigation. 

In  conclusion,  mishaps  are  an  unfortunate  yet  inevitable  product  of  the  practice  of 
aviation.  Naval  aviation  in  particular  provides  the  most  challenging  and  demanding 
environment  in  the  world  of  aviation.  From  the  flight  decks  of  carriers  to  the  cockpits  of 
patrol  aircraft  far  from  base,  naval  aviators  perform  feats  which  put  them  at  far  greater 
risk  than  other  aviation  communities,  and  thus  the  task  of  mishap  investigation  in  naval 
aviation  is  far  more  difficult  and  critical  to  their  survival.  The  occurrence  of  a  mishap 
obligates  us  to  rectify  undetected  hazards  through  investigation,  failure  to  detect  these 
hazards  dooms  us  to  eventually  repeating  our  mistakes  and  suffering  the  consequences 
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over  and  over.  Each  mishap  is  thus  an  opportunity  to  save  future  lives  and  assets,  but  if 
we  fail  to  logically  examine  evidence  or  consider  all  possible  scenarios  in  a  mishap,  we 
endanger  the  future  of  Naval  Aviation. 
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APPENDIX  A 


DATABASE  DESIGN 


A.  ANSI  SQL-92  SCHEMA 

CREATE  SCHEMA  MisDataBase 

CREATE  TABLE  Mishap 

( Mishap_Serial_Num  SMALLINT  NOT  NULL, 

EventDate  DATE  NOT  NULL, 

EventTime  TIME  NOT  NULL, 

Time_Zone  CHARACTER  VARYING  (1 0)  NOT  NULL, 

Location  CHARACTER  VARYING  (10), 

Unit_ID_FK2  INTEGER  NOT  NULL, 

Flight_lnformation_ID_FK3  INTEGER, 

Mishap_Summary  CHARACTER  VARYING  (1 0)  NOT  NULL, 

_ID  INTEGER  NOT  NULL, 

PRIMARY  KEY  (_ID), 

UNIQUE  ( Mishap_Serial_Num ), 

FOREIGN  KEY  ( Unit_ID_FK2  ) 

REFERENCES  Unit, 

FOREIGN  KEY  ( Flight_lnformation_ID_FK3 ) 

REFERENCES  Flightjnformation 

) 

CREATE  TABLE  MishapJRecommendations 

( Recommendations  CHARACTER  VARYING  (32000)  NOT  NULL, 

Mishap_ID_FK1  INTEGER  NOT  NULL, 

_ID  INTEGER  NOT  NULL, 

PRIMARY  KEY  (_ID), 

FOREIGN  KEY  (  Mishap_ID_FK1 ) 

REFERENCES  Mishap 

) 


CREATE  TABLE  Passenger 
( Person_ID_FK1 1 
Rank 
Rate 
Service 
USN 

Non_DoD 

Duty_Status 

Parent_Unit 

Lost_Wk_Days 

Hospital_Days 

Mishap_ID_FK14 


INTEGER  NOT  NULL, 
CHARACTER  VARYING  (10), 
CHARACTER  VARYING  (10), 
CHARACTER  VARYING  (10), 
CHARACTER  VARYING  (10), 
CHARACTER  VARYING  (10), 
CHARACTER  VARYING  (10), 
CHARACTER  VARYING  (10), 
SMALLINT, 

SMALLINT, 

INTEGER, 


ID 


INTEGER  NOT  NULL, 


PRIMARY  KEY  (_ID), 

FOREIGN  KEY  ( Person_ID_FK1 1  ) 
REFERENCES  Person, 
FOREIGN  KEY  ( Mishap_ID_FK14 ) 
REFERENCES  Mishap 


CREATE  TABLE  Unit 

(  Short_Name  CHARACTER  VARYING  (1 0)  NOT  NULL, 

UIC  CHARACTER  VARYING  (10)  NOT  NULL, 

PLAD  CHARACTER  VARYING  (10), 

AddressJ  CHARACTER  VARYING  (1 0)  NOT  NULL, 

Mlshap_Number  CHARACTER  VARYING  (10)  NOT  NULL 

JD  INTEGER  NOT  NULL, 

PRIMARY  KEY  (_ID), 

UNIQUE  ( UIC ) 

) 

CREATE  TABLE  Flight Jnformation 

( Origin  CHARACTER  VARYING  (1 0), 

Flight_Pur_Code  CHARACTER  VARYING  (10)  NOT  NULL, 

Mission  CHARACTER  VARYING  (1 0)  NOT  NULL, 

Destination  CHARACTER  VARYING  (10)  NOT  NULL, 

AirCraft_Evolution  CHARACTER  VARYING  (1 0)  NOT  NULL, 

Type_Flight_Plan  CHARACTER  VARYING  (3)  NOT  NULL, 

DayJMIght  CHARACTER  VARYING  (5)  NOT  NULL, 

WX_Desc  CHARACTER  VARYING  (32000)  NOT  NULL 

Altitude  SMALLINT  NOT  NULL, 

JD  INTEGER  NOT  NULL, 

PRIMARY  KEY  (JD ) 

) 

CREATE  TABLE  Mishap_Civilian_Fatalities 

( Civilian J=atalities  CHARACTER  VARYING  (1 0)  NOT  NULL, 

Mishap_ID_FK4  INTEGER  NOT  NULL, 

JD  INTEGER  NOT  NULL, 

PRIMARY  KEY  ( JD ), 

FOREIGN  KEY  ( MishapJD_FK4 ) 

REFERENCES  Mishap 

) 

CREATE  TABLE  Mishap_DoD_Fatalities 

( DoD_Fatalrties  CHARACTER  VARYING  (1 0)  NOT  NULL, 

Mishap JD_FK5  INTEGER  NOT  NULL, 

JD  INTEGER  NOT  NULL, 

PRIMARY  KEY  ( JD ), 
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FOREIGN  KEY  (  Mishap_ID_FK5 ) 
REFERENCES  Mishap 

) 


CREATE  TABLE  Crewmember 


( Person_ID_FK7 
Rank 
Rate 
Service 
Parent_Unit 
Duty_Status 
Hospital_Days 
NVG_Use 
Model_Hours 
Total_Hours 
Mishap_ID_FK10 
ID 


INTEGER  NOT  NULL, 

CHARACTER  VARYING  (10), 

CHARACTER  VARYING  (10), 

CHARACTER  VARYING  (10)  NOT  NULL, 
CHARACTER  VARYING  (10)  NOT  NULL, 
CHARACTER  VARYING  (10)  NOT  NULL, 
SMALLINT, 

CHARACTER  VARYING  (10)  NOT  NULL, 
INTEGER, 

INTEGER, 

INTEGER  NOT  NULL, 

INTEGER  NOT  NULL, 


PRIMARY  KEY  (_ID), 

FOREIGN  KEY  (  Person_ID_FK7 ) 
REFERENCES  Person, 
FOREIGN  KEY  ( Mishap_ID_FK10 ) 
REFERENCES  Mishap 

) 


CREATE  TABLE  Evidence 
( Enclosure_Number 
Description 
Summary_Number 
Summary 
Mishap_ID_FK16 
ID 


CHARACTER  VARYING  (4)  NOT  NULL, 
CHARACTER  VARYING  (10), 

BIT  (8)  NOT  NULL, 

CHARACTER  VARYING  (32000), 

INTEGER, 

INTEGER  NOT  NULL, 


PRIMARY  KEY  (_ID), 

UNIQUE  ( Enclosure_Number ), 
FOREIGN  KEY  ( Mishap_ID_FK16  ) 
REFERENCES  Mishap 

) 


CREATE  TABLE  Factor 
( Factor_Name 
Accept_or_Reject 
Explanation 
Mishap_ID_FK17 
ID 


CHARACTER  VARYING  (10)  NOT  NULL, 
CHARACTER  VARYING  (10)  NOT  NULL, 
CHARACTER  VARYING  (10)  NOT  NULL, 
INTEGER, 

INTEGER  NOT  NULL, 


PRIMARY  KEY  (_ID), 

UNIQUE  ( FactorJMame ), 
FOREIGN  KEY  ( Mishap_ID_FK17 ) 
REFERENCES  Mishap 

) 
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CREATE  TABLE  Causal_Factor 

(  Determination_Statement  CHARACTER  VARYING  (1 0)  NOT  NULL, 


Factor_ID_FK18 

RAC 

Who_or_Comp 

What_or_Mode 

Why_or_Agent 

Para_Number 

Mishap_ID_FK19 

ID 


INTEGER  NOT  NULL, 

CHARACTER  VARYING  (3)  NOT  NULL, 

CHARACTER  VARYING  (10)  NOT  NULL, 
CHARACTER  VARYING  (10)  NOT  NULL, 
CHARACTER  VARYING  (10)  NOT  NULL, 
CHARACTER  VARYING  (10)  NOT  NULL, 
INTEGER, 

INTEGER  NOT  NULL, 


PRIMARY  KEY  (_ID), 

FOREIGN  KEY  ( Factor_ID_FK18  ) 
REFERENCES  Factor, 
FOREIGN  KEY  ( Mishap_ID_FK19  ) 
REFERENCES  Mishap 


CREATE  TABLE  CF_Other_Dam 

(  Determination_Statement  CHARACTER  VARYING  (1 0)  NOT  NULL, 
Factor_ID_FK20  INTEGER  NOT  NULL, 

Who_Comp  CHARACTER  VARYING  (1 0)  NOT  NULL, 

What_or_Mode  CHARACTER  VARYING  (10), 

Why_or_Agent  CHARACTER  VARYING  (10), 

Mishap_ID_FK21  INTEGER, 

_ID  INTEGER  NOT  NULL, 

PRIMARY  KEY  (_ID), 

FOREIGN  KEY  ( Factor_ID_FK20 ) 

REFERENCES  Factor, 

FOREIGN  KEY  ( Mishap_ID_FK21  ) 

REFERENCES  Mishap 


CREATE  TABLE  Person 

(  Name  CHARACTER  VARYING  (1 0)  NOT  NULL, 

SSN  CHARACTER  VARYING  (10)  NOT  NULL, 

Address_1  CHARACTER  VARYING  (1 0), 

Phone_2  CHARACTER  VARYING  (1 0), 

Officer_RecallJD_FK6  INTEGER, 

_ID  INTEGER  NOT  NULL, 

PRIMARY  KEY  (_ID), 

FOREIGN  KEY  ( Officer_Recall_ID_FK6 ) 

REFERENCES  Officer  Recall 


CREATE  TABLE  Officer_Recall 

(  Position_AA  CHARACTER  VARYING  (1 0), 

_ID  INTEGER  NOT  NULL, 

PRIMARY  KEY  ( _ID  ) 
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) 


CREATE  TABLE  Crewmember_Position 

( Position_AA  CHARACTER  VARYING  (1 0)  NOT  NULL, 

Crewmember_ID_FK8  INTEGER  NOT  NULL, 

_ID  INTEGER  NOT  NULL, 

PRIMARY  KEY  (JD), 

FOREIGN  KEY  ( Crewmember_ID_FK8  ) 

REFERENCES  Crewmember 

) 

CREATE  TABLE  Crewmember_Signifigant_lnjuries 

( Signifigantjnjuries  CHARACTER  VARYING  (1 0)  NOT  NULL, 
Crewmember_ID_FK9  INTEGER  NOT  NULL, 

JD  INTEGER  NOT  NULL, 

PRIMARY  KEY  (JD), 

FOREIGN  KEY  ( CrewmemberJD_FK9 ) 

REFERENCES  Crewmember 

) 

CREATE  TABLE  Passenger J^sition 

( Position J\A  CHARACTER  VARYING  (1 0)  NOT  NULL, 

Passenger_ID_FK1 2  INTEGER  NOT  NULL, 

JD  INTEGER  NOT  NULL, 


PRIMARY  KEY  (JD), 

FOREIGN  KEY  ( PassengerJD_FK12 ) 

REFERENCES  Passenger 

) 

CREATE  TABLE  Passenger_SignifigantJnjuries 

( Signifigantjnjuries  CHARACTER  VARYING  (1 0)  NOT  NULL, 
Passenger_ID_FK1 3  INTEGER  NOT  NULL, 

JD  INTEGER  NOT  NULL, 


PRIMARY  KEY  (JD), 

FOREIGN  KEY  ( PassengerJD_FK13 ) 
REFERENCES  Passenger 

) 


CREATE  TABLE  Unit  Phone  2 


( Phone_2 
UnitJD_FK15 
ID 


CHARACTER  VARYING  (10)  NOT  NULL, 
INTEGER  NOT  NULL, 

INTEGER  NOT  NULL, 


PRIMARY  KEY  (  JD  ), 
FOREIGN  KEY  ( UnitJD_FK15 ) 
REFERENCES  Unit 

) 
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B.  SEMANTIC  OBJECT  REPRESENTATION 


Mishap 

ID  Mishap_SeriaLNum 
EventDate 
EventTime 
Time_Zone 
Recommendations 
Location 


Civilian__Fatalitie$ 
Mishap_Summary 
DoD  Fatalities 


Evidence 

JD  Enclosure_Number 
Description 
Summary_Number 
Summary 


Person 


Address_1 
Phone  2 


i  Crewmember 


Crewmember 

|  Person  [  1  1 
Position 


Service 

Parent_Unit 

Duty_Status 

Signifigantjnjuries 

Hospital_Days 

NVG_Use 

Modef_Hours 

Total  Hours 


Crewmember 


Causal  Factor 


Officer  Recall  \, 


Recall 


Causal  Factor 


Determination  Statement 


Passenger 


CF_Other_Dam 


ID  Factor_Name 
Accept_or__Reject 
Explanation 
[Causal  Factor  I  „ 


CF_Other  Dam 


Mishap 


Unit 


Short  Name 


ID  UIC 


Address_1 

Phone__2 

Mlshap_Number 


Who_or_Comp 

What_or_Mode 

Why_or_Agent 

Para_Number 


Flight  Information 


F!ight_Pur_Code 

Mission 

Destination 

AirCraft_Evolution 

Type_Flight_Plan 

Day_Nlght 

WX  Desc 


Altitude 


Mishap 


Position 


Service 


Non_DoD 

Duty_Status 

Parent_Unit 

Lost_Wk_Days 

Signifigantjnjuries 

Hospita!_Days 

|  Mishap  L., 
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APPENDIX  B 


NOTEBOOK  SOURCE  CODE 

(WRITTEN  BY  LT  HUGH  BRIAN,  USN) 


unit  Noteform; 
interface 

uses  SysUtils,WinTypes,  WinProcs,  Classes,  Graphics,  Forms,  Controls,  Menus, 
Dialogs,  StdCtrls,  Buttons,  ExtCtrls,  TabNotBk,  Grids,  IniFiles,  Tabs,  Spin, 
Printers, Gauges,  Aboutnot,  Mask,  Diagl,  Printgd; 

type 

TNoteBookForm  =  class(TForm) 

MainMenu:  TMainMenu; 

FileMenu:  TMenuItem; 

Saveltem:  TMenuItem; 

Exitltem:  TMenuItem; 

Nl:  TMenuItem; 

SaveDialog:  TSaveDialog; 

Helpl:  TMenuItem; 

About  1:  TMenuItem; 

StatusBar:  TPanel; 

Notebook:  TTabbedNotebook; 

Gridl  :  TStringGrid; 

MishapPanel:  TPanel; 

MishapCategory:  TComboBox; 

Yesl:  TButton; 

Panel  1:  TPanel; 

MishapSeverity:  TComboBox; 

SeverityDone:  TButton; 

OprepMemo:  TMemo; 

GroupBox7:  TGroupBox; 

OprepPOC:  TComboBox; 

OprepType:  TComboBox; 

Notebookl:  TNotebook; 

Label7:  TLabel; 

Label8:  TLabel; 
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Label  10:  TLabel; 

CallerName:  TEdit; 
CallerOrganization:  TEdit; 
MishapLocation:  TEdit; 

GroupBox3:  TGroupBox; 
MishapDescriptionMemo:  TMemo; 
GroupBoxl  1 :  TGroupBox; 

Weather:  TMemo; 

DayNiteSel:  TRadioGroup; 
GroupBoxl3:  TGroupBox; 

Label35:  TLabel; 

Label36:  TLabel; 

Label37:  TLabel; 

Label38:  TLabel; 

Label40:  TLabel; 

Origin:  TEdit; 

MissionCode:  TComboBox; 

FPC:  TComboBox; 

Destination:  TEdit; 

AirEvol:  TEdit; 

TabSetl:  TTabSet; 

Panel5:  TPanel; 

UnitName:  TLabel, 

Label3:  TLabel; 

Address:  TLabel; 

Label2:  TLabel; 

Label  15:  TLabel; 

AircraftTypeLabel:  TLabel; 
SquadronName:  TEdit; 

UnitPlad:  TEdit; 

SAddress:  TEdit; 

SState:  TEdit; 

AircraftTypeComboBox:  TComboBox; 
GroupBox2:  TGroupBox; 

CheckBox2:  TCheckBox; 

CheckBox3:  TCheckBox; 

CheckBoxl:  TCheckBox; 

CheckBox4:  TCheckBox; 

CheckBox5:  TCheckBox; 

CheckBox6:  TCheckBox; 

CheckBox7:  TCheckBox; 

CheckBox8:  TCheckBox; 

CheckBox9:  TCheckBox; 
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CheckBoxll:  TCheckBox; 

SCVoice:  TMemo; 

Timerl:  TTimer; 

POCPhone:  TComboBox; 

CadPlad:  TComboBox; 

TYCOM:  TComboBox; 

WingCom:  TComboBox; 

Label4:  TLabel; 

Label9:  TLabel; 

DodDead:  TRadioGroup; 

CivDead:  TRadioGroup; 

Grid2:  TStringGrid; 

Gauge  1:  TGauge; 

Labelll:  TLabel; 

UpdateUnitlnfo:  TButton; 

Label  13:  TLabel; 

Labell4:  TLabel; 

GroupBox5:  TGroupBox; 

Label5:  TLabel; 

Label  1:  TLabel; 

Label6:  TLabel; 

LocalTime:  TEdit; 

ZuluTime:  TEdit; 

DateAndTime:  TEdit; 

UpdateTime:  TButton; 

Label  17:  TLabel; 

ZuluTimeSet:  TSpinEdit; 

Labell8:  TLabel; 

LatLong:  TEdit; 

Label  19:  TLabel; 

FlightPlan:  TComboBox; 

Label22:  TLabel; 

Altitude:  TEdit; 

Label39:  TLabel; 

ACGrid:  TStringGrid; 
SaveOprepVoiceReportl:  TMenuItem; 
OPREPMessagel:  TMenuItem; 
SafetyCenterVoiceReportl:  TMenuItem; 
MishapReportl:  TMenuItem; 

Contents  1:  TMenuItem; 

Panel2:  TPanel; 

UpdateMisAircraft:  TButton; 
AircraftNumber:  TSpinEdit; 


71 


Label23:  TLabel; 

Panel3:  TPanel; 

Button3:  TButton; 

NumberCrew:  TSpinEdit; 

Label24:  TLabel; 

PersGrid:  TStringGrid; 

ShipPlad:  TEdit; 

Label  12:  TLabel; 

ComPhoneLabel:  TLabel; 

AutovonLabel:  TLabel, 

LTime:  TEdit; 

ZTime:  TEdit; 

Print  1:  TMenuItem; 

OprepVoiceReportl:  TMenuItem; 
OPREPMessage2:  TMenuItem; 
SafetyCenterVoiceReport2:  TMenuItem; 
MishapReport2:  TMenuItem; 
PrintDialogl:  TPrintDialog; 

N2:  TMenuItem; 

StartTimer:  TButton; 

Panel4:  TPanel; 

Button2:  TButton; 

PaxGrid:  TStringGrid; 

TabContinue:  TButton; 

MisSevQl  :  TRadioGroup; 

MisSevQ2:  TRadioGroup; 

MisSevQ3:  TRadioGroup; 

MisSevQ4:  TRadioGroup; 

MisSevQ5:  TRadioGroup; 

Damage:  TRadioGroup; 

Injury:  TRadioGroup; 

CheckBoxl2:  TCheckBox; 
MishapNumber:  TSpinEdit; 

Label27:  TLabel; 

ServiceSel:  TRadioGroup; 

FleetCom:  TComboBox; 

Label20:  TLabel; 

UniCom:  TComboBox; 

Label21:  TLabel; 

UIC:  TEdit; 

Label29:  TLabel; 

Label30:  TLabel; 

Panel7:  TPanel; 
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Panel8:  TPanel; 

MsgMemo:  TMemo; 
OprepRemarks:  TMemo; 

Panel9:  TPanel; 

Panel  10:  TPanel; 

Panel6:  TPanel; 

Label26:  TLabel; 

ALSSBox:  TCheckBox; 
CarLandBox:  TCheckBox; 
HeloLandBox:  TCheckBox; 
SarCheckBox:  TCheckBox; 
MishapReport:  TMemo; 

Panelll:  TPanel; 

GroupBoxl:  TGroupBox; 

Label  16:  TLabel; 

PaxNumber:  TSpinEdit; 
GroupBox4:  TGroupBox; 

Label3 1 :  TLabel; 

InjuredPax:  TSpinEdit; 
GroupBox6:  TGroupBox; 
Label32:  TLabel; 
InjuredNonOccupants:  TSpinEdit; 
AVPhone:  TMaskEdit; 
ComPhone:  TMaskEdit; 

Szip:  TEdit; 

Panel  13:  TPanel; 

OfficerRecalll:  TMenuItem; 
BitBtn3:  TBitBtn; 

BitBtnl:  TBitBtn; 

BitBtn2:  TBitBtn; 

BitBtn4:  TBitBtn; 

BitBtn5:  TBitBtn; 

BitBtn6:  TBitBtn; 

BitBtn7:  TBitBtn; 

BitBtn8:  TBitBtn; 

BitBtn9:  TBitBtn; 

BitBtnl 0:  TBitBtn; 

BitBtnl  1:  TBitBtn; 

BitBtnl2:  TBitBtn; 

BitBtnl  3:  TBitBtn; 

BitBtnl 4:  TBitBtn; 

BitBtnl 5:  TBitBtn; 

BitBtnl 6:  TBitBtn; 


BitBtnl  8:  TBitBtn; 

BitBtnl9:  TBitBtn; 

BitBtn20:  TBitBtn; 

BitBtn21:  TBitBtn; 

BitBtn22:  TBitBtn; 

Panel  12:  TPanel; 

UpdateOfficer:  TButton; 

RecallMemo:  TMemo; 

BitBtnl 7:  TBitBtn; 

BitBtn23:  TBitBtn; 

BitBtn24:  TBitBtn; 

procedure  ShowHint(Sender:  TObject); 
procedure  ExitItemClick( Sender:  TObject); 
procedure  FormCreate(Sender:  TObject); 
procedure  UpdateOfficerClick( Sender:  TObject); 
procedure  MishapCatDoneClick(Sender:  TObject); 
procedure  TabSetlClick( Sender:  TObject); 
procedure  TimerlTimer(Sender:  TObject); 
procedure  StartTimerClick(Sender:  TObject); 
procedure  UpdateOprepClick(Sender:  TObject); 
procedure  OprepPOCChange(Sender:  TObject); 
procedure  UpdateOPClick(Sender:  TObject); 
procedure  FormResize( Sender:  TObject); 
procedure  UpdateUnitInfoClick(Sender:  TObject); 
procedure  UpdateSafetyCallClick(Sender:  TObject); 
procedure  UpdateMRClick(Sender:  TObject); 
procedure  UpdateTimeClick(Sender:  TObject); 
procedure  UpdateMishapClick(Sender:  TObject); 
procedure  AircraftNumberChange(Sender:  TObject); 
procedure  NumberCrewChange(Sender:  TObject); 
procedure  About  lClick(Sender:  TObject); 
procedure  InjuredPaxChange(Sender:  TObject); 
procedure  UpdateMisAircraftClick(Sender:  TObject); 
procedure  Contents  lClick(Sender:  TObject); 
procedure  MishapReportlClick(Sender:  TObject); 
procedure  SafetyCenterVoiceReportlClick(Sender:  TObject); 
procedure  SaveOprepVoiceReportlClick(Sender:  TObject); 
procedure  OPREPMessagelClick(Sender:  TObject); 
procedure  Button2Click(Sender:  TObject); 
procedure  AircraftTypeComboBoxChange(Sender:  TObject); 
procedure  OprepVoiceReportlClick(Sender:  TObject); 
procedure  OPREPMessage2Click(Sender:  TObject); 
procedure  SafetyCenterVoiceReport2Click(Sender:  TObject); 
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procedure  MishapReport2Click( Sender:  TObject); 
procedure  TabContinueClick(Sender:  TObject); 
procedure  InfoCompClick(Sender:  TObject); 
procedure  MishapInfoCompleteClick(Sender:  TObject); 
procedure  CompeteNextClick(Sender:  TObject); 
procedure  Button7Click(Sender:  TObject); 
procedure  YeslClick(Sender:  TObject); 
procedure  Button6Click(Sender:  TObject); 
procedure  GotoMishapCatClick( Sender:  TObject); 
procedure  CompleteMishapCatClick(Sender:  TObject); 
procedure  MishapSevDoneClick(Sender:  TObject); 
procedure  Button8Click(Sender:  TObject); 
procedure  MRCompleteClick(Sender:  TObject); 
procedure  OfficerRecalllClick(Sender:  TObject); 
private 

{ Private  declarations } 
public 

{ Public  declarations } 
end; 

var 

NoteBookForm:  TNoteBookForm; 

type  TMishapCLass  =  (ClassA,ClassB,ClassC); 
const 

ScreenWidth:  Longlnt  =  640;  {I  designed  my  form  in800x600  mode.} 
ScreenHeight:  Longlnt  =  480; 


implementation 
{$R  *.DFM) 


procedure  TNoteBookForm.  ShowHint(Sender:  TObject); 
begin 

StatusBar. Caption  :=  Application.Hint; 
end; 

procedure  TNoteBookForm.ExitItemClick(Sender:  TObject); 

begin 

Close; 
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end; 


procedure  TNoteBookForm.FormCreate(Sender:  TObject); 
var 

Intro:  TlntroForm;  {IntroForm  pusedo  splash  screen) 

Notebooklni:  TlniFile; 

R,C,I:  Integer;  (Counters) 

Name,  Phone:  String; 

UnitlnfoList:  TStringList; 

x,  y:  Longlnt;  (Integers  will  not  not  a  large  enough  value.) 
begin 

(Screen  Settings) 

(this  comes  to  you  with  courtesey  from  Loyd  of  Borland  Tech  Support) 
NoteBookForm.  scaled  :=  true; 
x  :=  getSystemMetrics(SM_CXSCREEN); 
y  :=  getSystemMetrics(SM_C Y SCREEN); 
if  (x  o  ScreenHeight)  or  (y  o  ScreenWidth)  then 
begin 

NoteBookForm.height  :=  NoteBookForm.height  *  y  DIV  ScreenHeight; 
NoteBookForm. width  :=  NoteBookForm.width  *  x  DIV  ScreenWidth; 
scaleBy(x,  ScreenWidth); 
end; 

(End  Screen  Settings) 

(Initial  Settings  } 

TabSetl.Tabs  :=  Notebook  1. Pages; 

Notebook.PageIndex:=0; 

Application.  OnHint  :=  ShowHint; 

Labell  1  .Transparent:=True; 

(set  combo  boxes  to  first  item) 
for  i:=  0  to  GroupBox7.ControlCount  -1  do 
T  ComboBox(GroupBox7 .  Controls[i] ) .  Itemlndex:  =0; 

(Update  time  and  date  stamp  when  program  loads) 

UpdateTime.  Click; 

(Start  mishap  timer) 

StartTimer.  Click; 

(Create  List  for  retrieving  valuse  from  Ini  File) 

UnitInfoList:=TStringList.  Create; 

(NoteBok.ini  file  initialization) 

NoteBookIni:=  TlniFile.Create('notebook.ini'); 
for  R:=  1  to  Gridl.RowCount-1  do  begin 

GridLCells[l,R]:=NoteBookIni.ReadString('OfficerRecair,  'Name'  + 
IntToStr(R),fNAME'), 
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Gridl  Cells[2,R]:=  NoteBookIni.ReadString('OfificerRecair,  Unitld'  + 
IntToStr(R),SquadronName.Text); 

Gridl.Cells[3,R]:=  NoteBookIni.ReadString('OflficerRecair,  'CPhone'  + 
IntToStr(R),,COMPHONE'); 

Gridl  Cells[4,R]:=  NoteBooklni.ReadStringCOfficerRecaH',  'APhone'  + 

IntT  o  Str(R),' AUT  O  VON#'); 
end; 

for  R:=  1  to  Gridl.RowCount-1  do  begin 

Grid2.Cells[l,R]~  NoteBooklni.ReadStringCMisBoard',  'Name'  + 
IntToStr(R),'NAME'); 

Grid2.Cells[2,R]:=  NoteBookIni.ReadString(’MisBoard',  'Unitld'  + 
IntToStr(R),SquadronName.  T  ext); 

Grid2.Cells[3.,R]:=  NoteBooklni.ReadStringCMisBoard',  'CPhone'  + 

IntT  oStr(R),'COMPHONE'); 

Grid2.Cells[4,R]:=  NoteBooklni.ReadStringCMisBoard',  'APhone'  + 
IntToStr(R),'AUTOVON#'); 
end; 

{Read  in  Unitlnfo  into  TSTringList) 
NoteBookIni.ReadSectionValues('UnitInfo',UnitInfoList); 

{Assign  values  from  List  to  edit  boxes) 

SquadronName.Text:=UnitInfoList.Values['UnitName']; 

UnitPlad.Text:=UnitInfoList.Values['UnitPlad']; 

S  Address.  Text:  =UnitInfoList .  Values[' Address'] ; 

S  State.  Text :  =UnitInfoList .  Values['  State'] ; 

SZip .  T  ext:=UnitInfoList.  Values['Zip']; 

ShipPlad.Text:=UnitInfoList.Values['ShipPlad']; 

AircraftTypeComboBox.Text:=UnitInfoList.Vahies['AircraftType']; 

CadPlad .  Text :  =U  nitlnfoList .  V  alues['C  ADPlad'] ; 

AVPhone.Text:=UnitInfoList.Values['AVPhone']; 

ComPhone.Text:=UnitInfoList.Values['ComPhone']; 

TYCOM.Text:=UnitInfoList.Values['Tycom']; 

Wingcom.Text:=UnitInfoList.Values['Wingcom']; 

FleetCom.  Text:=  UnitlnfoList.  Values[TleetCom'] ; 

UniCom.  Text :  =  UnitlnfoList .  ValuesfUnifiedCom'] ; 
ZuluTimeSet.Value:=NoteBookIni.ReadIntegerCUnitInfoVZuluTimeSet',  0); 
MishapNumber.Value:=NoteBookIni.ReadInteger('UnitInfoVMishapNumber',  0); 
ServiceSel.ItemIndex:=NoteBookIni.ReadInteger(,UnitInfoVServiceSel',0); 
UIC.Text:=  UnitlnfoList.  ValuesfUIC']; 

NoteBooklni.Free; 

UnitlnfoList.Free; 

{Fill  Grid  Labels) 

Gridl  Cells[050]:=  'Officer  Recall'; 
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Grid  1 .  Cells[0, 1  ]:=  'CO/OIC'; 
Gridl.Cells[0,2]:=  'XO'; 

Gridl.Cells[0,3]:=  'OPS  Officer', 
Gridl.CeUs[0,4]:=  'Maint,  Officer'; 
Gndl.Cells[0,5]:=  Tlight  Surgeon'; 
Gridl.Cells[0,6]:=  'ASO'; 
Gridl.Cells[0,7]:=  'Safety  Officer'; 
Gridl.Cells[0,8].-  'CACCO  Officer'; 
Gridl.Cells[0,9]:=  'PAO  Officer'; 

{Grid  One  Label  fill} 

Grid  l.Cells[  1,0]:=  'Rank&Name'; 
Gridl.Cells[2,0]:=  'Squadron'; 
Gridl.Cells[3,0]:=  Home  Phone'; 
Gridl.Cells[4,0]:=  'DNS  Work  Phone'; 

Grid2.Cells[0,0]:=  Proposed  Mishap  Board'; 
Gnd2.Cells[0,l]:=  'AMB  Senior  Member'; 
Grid2.Cells[0,2]:=  Tlight  Surgeon'; 
Gnd2.Cells[0,3]:=  Maint.  Officer'; 
Grid2.Cells[0,4]:=  'OPS  Officer'; 
Grid2.Cells[0,5]:=  'Other'; 

Grid2.Cells[l,0]:=  Rank&Name'; 
Grid2.Cells[2,0]:=  'Squadron'; 
Grid2.Cells[3,0]:=  'Home  Phone'; 
Grid2.Cells[4,0]:=  'DNS  Work  Phone'; 

{fill  Aircrew  data  label} 
PersGrid.Cells[0,0];='Positiori; 

PersGrid .  Cellsf  1 ,0] :  =Rank'; 
if  ServiceSel.Itemlndex  =  1  then 
PersGrid.Cells[2,0]:=MOS'  else 
PersGrid.Cells[2,0]:='Desg/NEC'; 

PersGrid.  Cells[3,0]:=' Service'; 

PersGrid.  Cells[4,0]  :=ParentUnit'; 

PersGrid.  Cells[5,0]  :=DutyStatus'; 
PersGnd.Cells[6,0]:-  Sig.Injuries'; 

PersGrid.  Cells[7,0]  :=Hosp.Days'; 

PersGrid.  Cells[8,0]  :=Lo  st  WkDays'; 
PersGrid.Cells[9,0]:=’NVGS  USED'; 
PersGrid.  Cells[l  0,0]  :='TOTAL  HOURS'; 
PersGrid.CeUs[ll,0]:=MODEL  HOURS'; 
{Fill  Aircraft  Data  Labels} 
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ACGrid.Cells[0,0]:- Model'; 

ACGrid.Cells[  1 ,0]:  bureau#'; 

ACGrid.  Cells[2,0]:='Side#'; 

ACGrid.  Cells[3 ,0]  :='Unit'; 
ACGrid.Cells[4,0]:='EngineType/Model/Series'; 

ACGrid.  Cells[5,0]:='EngineSerial#'; 

ACGrid.  Cells[6,0]  :=' EquipmentModel'; 
ACGrid.Cells[7,0]:-EquipmentMake'; 

ACGrid.  Cells[8,0]  —'EquipmentPart#'; 

ACGrid.  Cells[9,0]  :=,EquipmentCode#'; 

(FILL  INJURED  PASSENGER  DATA  FIELD} 

PaxGrid  Cells[0,0]  :='RANK'; 
if  ServiceSel.Itemlndex  =  1  then  begin 
PaxGrid.  Cells[l,0]:=MOS'; 

PaxGrid.  Cells[2,0] :  =rU  SMC'; 
end  else  begin 

PaxGrid.Cells[l,0]:=T>ESG.'; 

PaxGrid.Cells[2.,0]:='USN/DOD'; 

end; 

PaxGrid.Cells[3,0]:=DOD/Non-DOD'; 

PaxGrid.CeUs[4,0]~Unit'; 

PaxGrid.Cells[5,0]:=  'Duty  Status'; 

PaxGrid.  Cells[6,0]  :-InjuryType'; 

PaxGrid.CeUs[7,0]  :='InjuryDesc'; 

PaxGrid.Cells[8,0]:='HospitalDays'; 

PaxGrid.Cells[9,0]:='LostWorkDays'; 

(Create  Intro  Screen} 

Intro:=  TIntroForm.Create(self); 

Intro .  ShowModal; 

if  Intro.ModalResult  =  mrNo  then  Intro.Free 
else  begin 

Notebook.PageIndex:=  9; 

Intro.Free 

end; 

end;  (End  ofMainForm  Create} 

(Officer  recall  update  to  the  NoteBok.INI  file 
Updates  the  officer  recall  list  gridBox  and  the  mishap 
board  GridBox} 

procedure  TNoteBookForm.UpdateOfficerClick(Sender:  TObject); 
var 

R,  C:  Longlnt; 
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NoteBooklni:  TlniFile; 
begin 

(Write  Officer  Recall  to  NoteBoklni} 

if  MessageDlg('Are  you  sure  you  want  to  change  OFFICER  RECALL 
Information?',mtConfirmation,mbOKCancel,0)  =  mrOk 
then  begin 

NoteBookIni:=  TlniFile.Create('notebook.ini'); 
for  R:=  1  to  Gridl.RowCount-1  do  begin 
with  NoteBooklni  do  begin 

WriteString('OfficerRecair,'Name'+IntToStr(R),  Grid  1  .Cells[  1  ,R]); 
WriteString('OfficerRecaU',TJnitId'  +  IntToStr(R),  Gridl.Cells[2,R]); 
W riteS tringCOfficerRecall1, 'CPhone'+IntT o Str(R),  Grid  1  .Cells[3,R]); 
WriteString('OfficerRecall V APhone'  +IntTo  Str(R),  Grid  1 .  Cells[4,RJ); 
end; 
end; 

for  R:=  1  to  Grid2.RowCount-l  do  begin 
with  NoteBooklni  do  begin 

WriteString('MisBoard',rName'+IntToStr(R),  Grid2.Cells[l,R]); 
WriteStringCMisBoard^TJnitld'  +  IntToStr(R),  Grid2.Cells[2,R]); 
WriteStringCMisBoardVCPhone'+IntToStr(R),  Grid2.Cells[3,R]); 
W riteStringCMisBoardV APhone'  +IntToStr(R),  Grid2.Cells[4,R]); 
end; 
end; 

NoteBooklni.Free; 

end; 

end; 

(Don't  delelte} 

procedure  TNoteBookForm.MishapCatDoneClick(Sender:  TObject); 
var 

MishapType,  MishapInjury:TMishapClass; 
begin 

if  (Damage.Itemlndex  =  0)  or  (Damage.Itemlndex  =1) 
then  MishapType:=  ClassA; 

if  (Damage.Itemlndex  =  2)  then  MishapType:=ClassB; 
if  (Damage.Itemlndex  =  3)  then  MishapType:=ClassC; 

if  (Injury. Itemlndex  =  0)  or  (Injury.  Itemlndex  =1) 
then  Mishaplnjury—  ClassA; 
if  (Injury. Itemlndex  =  2)  or  (Injury. Itemlndex  =  3) 
then  Mishaplnjury— ClassB; 
if  (Injury.Itemlndex  =  4)  then  MishapInjury:=ClassC; 
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if  (MishapType  =  ClassA)  or  (Mishaplnjury  =  ClassA) 
then  Mishap S everity .  Itemlndex :  =  0  else 
if  (MishapType  =  ClassB)  or  (Mishaplnjury  =  ClassB) 
then  MishapSeverity.ItemIndex:=  1  else 
if  (MishapType  =  ClassC)  or  (Mishaplnjury  =  ClassC) 
then  MishapSeverity.  Itemlndex  -  2; 


end; 

{Determine  mishap  severity } 

procedure  TNoteBookForm.TabSetlClick(Sender:  TObject); 
begin 

Notebook  1  .Pagelndex”  TabSetl  .Tablndex; 
end; 

procedure  TNoteBookForm.TimerlTimer(Sender:  TObject); 
var 

minutes:integer; 

begin 

Timer  1  .Tag”Timerl  .TAg+1; 

Gauge  1. Progress”  Timerl.Tag; 

Labell  1  Caption”  IntToStr(Timerl  .Tag)  + '  Minutes  of  60  into  Mishap'; 
if  (Timerl  Tag  =  5)  then 

MessageDlg('OPREP-3  Voice  Report  Due.  OPREP-3  Message  due  in  15 
miniutes',mtInformation,  [mbOk],  0); 
if  (Timerl.Tag  =  20)then 

MessageDlg('OPREP-3  Message  Due.',mtInformation,  [mbOk],  0); 
if  (Timerl  .Tag  =  60)then 

MessageDlg('Safety  Center  Voice  Report  Due.',mtInformation,  [mbOk],  0); 
if  (Timerl  .Tag  =  30)then 

MessageDlg(Mishap  Report  Due  in  3.5  hours  ',mtInformation,  [mbOk],  0); 
if  (Timerl  Tag  =  60)then 

MessageDlgCMishap  Report  Due  in  3  hours  ',mtInformation,  [mbOk],  0); 
if  (Timerl.Tag  =  120)then 

MessageDlgCMishap  Report  Due  in  2  hours  ',mtInformation,  [mbOk],  0); 
end; 

procedure  TNoteBookForm.StartTimerClick(Sender:  TObject); 
begin 

Timerl  ,Enabled~True; 
end; 
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{Update  Oprep  Voice  Report} 

procedure  TNoteBookForm.UpdateOprepClick(Sender:  TObject); 
var 

Report:TStringList; 

i:integer; 

begin 

checkBox6. Checked”  True; 

Report  :=T  StringList.  Create; 

OprepMemo.LInes.  Clear; 

With  Report  do  begin 
Add(DateAndTime.  Text); 

Add(' '); 

Add(OprepPOC.Text  +'  THIS  IS  '  +  SquadronName.Text  +  '  OPREP-3  '  + 
OprepType.Text  + '  OVER.'); 

Add(' '); 

Add('Response:'); 

Add(""+SquadronName.Text  +  '  THIS  IS  '  +  OprepPOC.Text  + SEND  OPREP-3  '  + 
OprepType.Text  + '.'+""); 

Add(' '); 

Add(OprepPOC.Text  +'  THIS  IS  '  +  SquadronName.Text); 

Add(#13); 

If  OprepType.Itemlndex  =  0  then 
AddCFLASH)  else  AddCIMMEDIATE'); 

Add('OPREP-3  '+  OprepType.Text); 

Add(' '); 

Add('UNCLAS  SEFIED'); 

AddCLINE  1.  N/A'); 

Add("); 

Add('LINE  2: '+  MishapLocation.Text); 

Add("); 

Add('LINE  3: '+  MishapDescriptionMemo.Text); 

{filler  so  file  will  write  to  disk} 
for  i:=l  to  30  do 
Add('  ’); 
end; 

OprepMemo.LInes”  Report; 

Report.Free; 

end; 

{Synchonize  POC  PHone  Number  with  phone  list} 
procedure  TNoteBookForm.OprepPOCChange(Sender:  TObject); 
begin 

POCPhone.  Itemlndex”  OprepPOC .  Itemlndex; 
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end; 

{Update  OPREP  Message} 

procedure  TNoteBookFortn.UpdateOPClick(Sender:  TObject); 
var 

Report,T  empList :  TStringList; 

ij:  integer; 

begin 

Checkbox5  ,Checked:=True; 

Report:=TStringList.Create; 

MsgMemo  .Lines.  Clear; 

With  Report  do  begin 

AddCPAAUZYUW  JuhanDate  -UUUU-  .'); 

Add('ZNRUUUUU); 

AddCP '+  DateAndTime.Text+'  YZB'); 

Add(-); 

Add('FM:  ’+UnitPlad.Text); 

Add('TO:  CNO  WASHINGTON  DC  //JJJ//'); 

Add('  '+  FleetCom.Text  +  '//JJJ//'); 

Add('  '+  UniCom.text+  '//JJJ//'); 

Add('  '  +  TYCOM.Text+ '  //JJJ//'); 

Add('  '  +  WingCom.Text  + '  //JJJ//'); 

Add('INFO: '); 

Case  Injury.ItemINdex  of 
0:  begin 

if  (ServiceSel.Itemlndex  =  1)  then  Add(’  CMC  WASHINGTON  DC//JJJ//'); 
Add('  CNO  NOVEMBER  ONE  WASHINGTON  DC  //JJJ//'); 

Add('  CHNAVPERS  WASHINGTON  DC  //JJJ//'); 

Add('  COMNISCOM  WASHINGTON  DC  //22D//*); 
end; 

1, 2,3,4:  begin 

if  (ServiceSel.Itemlndex  =  1)  then  Add('  CMC  WASHINGTON  DC//JJJ//'); 
Add('  CNO  NOVEMBER  ONE  WASHINGTON  DC  //JJJ//'); 

Add('  CHNAVPERS  WASHINGTON  DC  //JJJ//’); 
end; 

end; 

{if  DoDDead.Itemlndex  =  0  then  begin} 


if  CivDeadJtemlndex  =  0  then  Add('  NAVY  JAG  ALEXANDRIA  VA'); 
Add(’  COMNAVAIRS  YSCOM  WASHINGTON  DC//JJJ//1); 

Add(’  COMN AV S AFECEN  NORFOLK  VA  //00/10/1 1/541//*); 

Add('  NAVMARINTCEN  WASHINGTON  DC  //JJJ//'); 
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Add('BT'); 

Add('UNCLAS'); 

Add('MSGID/OPREP-3NB/'+SquadronName.Text+  700'  + 
IntToStr(MishapNumber.Value)+'/' 

+  FormatDateTime('mmm',StrToDateTime(ZTime.Text))  +  7/'); 
Add('REF/A/OPREP-3NB/'+SquadronNarne.Text  +  7'+  DateAndTime.Text  +  7 7); 
Add(TLAGW  ORD/'+  OPREPT  YPE .  T  ext  +  7 -IF); 

Add('TIMELOC/'  +  DateAndTime.Text+7'  +  LatLong.Text  +  '/INIT//'); 
Add('GENTEXT/INCIDENT  IDENTIFICATION  AND  DETAILS/'); 
Add(MishapLocation.  T  ext); 

Add(Mi  shapDescriptionMemo .  Text) ; 

Add(MISHAP  DATA.'); 

Add(' AIRCRAFT  DATA.'); 

TempList:=TStringList.Create; 

T  empList : = AddGridList(  ACGrid); 

AddStrings(TempList); 

TEmpList.Free; 

Add(’CUSTODIAN  LOCATION. '+  ShipPlad.text); 

AddCMISSION.  '+  MissionCode.Text); 

AddCE  VOLUTION.  ’+  AirEvol.Text); 

Add(' AIRCREW  AND  PASSENGERS.  SOULS  ONBOARD  ’  + 

IntT  oStr(NumberCrew.  V  alue+PaxNumber .  V  alue)); 

Add('SAR  STATUS. ’); 

Ad  d(7/’); 

Add("); 

AddCRMKS/1); 

Add(OprepRemarks .  Text+7/1); 

AddCBT’); 

Add(Grid  1 .  Cells[  1 , 1  ]+ ',  COMMANDING  OFFICER,  ’+  SquadronName.Text); 
end; 

MsgMemo.LInes:=  Report; 

Report  Free; 
end; 

procedure  TNoteBookForm.FormResize(Sender:  TObject); 
begin 

Labell  1  .Left:=  Gaugel .Width  div  2  -  Labell  1  Width  div  2; 
end; 

(CheckList  Update  } 

procedure  TNoteBookForm.UpdateUnitInfoClick(Sender:  TObject); 
var 
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NoteBookIni:TIniFile; 

R,C:  integer; 
begin 

if  MessageDlg('Update  Squadron  Information?', mtConfirmation,mbOKCancel,0)  =  mrOk 
then  begin 

NoteBookJni:=  TIniFile.Create('notebook.ini'); 
with  NoteBooklni  do  begin 

WriteStringCUnitInfo',UnitName',SquadronName.Text); 

W  riteString(UnitInfo','UnitPlad',UnitPlad.  T  ext) ; 

WriteString(UnitInfo  V  Address',  S  Address .  T  ext); 
WriteString(XJnitInfoVState',SState.Text); 

WriteString(TJnitInfo ','Zip',  SZip.  T  ext); 
WriteString('UnitInfo','ShipPlad',ShipPlad.Text); 
WriteString(TJnitInfoVAircraftType',AircraftTypeComboBox.Text); 
WriteString(UnitMo','CADPlad',CADPlad.Text); 

WriteString(UnitInfo',' AVPhone',  AVPhone.  T  ext); 
WriteString('UnitInfoVComPhone',ComPhone.Text); 

WriteStringCUnitlnfo ','Tycom',T  Y  COMText); 
WriteString(UnitInfo','WmgCom',WingCom.Text); 
WriteInteger(UnitInfo','ZuluTimeSef,ZuluTimeSet.  Value); 
WriteInteger(UnitInfo','MishapNumber',MishapNumber.  Value), 
WriteIntegerCUnitInfoVServiceSer,ServiceSel.ItemIndex); 
WriteString(TJnitInfo','UIC',UIC .  T  ext); 

WriteStringCUnitlnfo', TleetCom',FleetCom.Text); 
WriteString(UnitInfo',UnifiedCom',UniCom.  T  ext), 
for  R  :=  1  to  Gridl.RowCount  - 1  do 
Grid  1  .Cells[2,R]  :=SquadronName.  Text; 
for  R:=  1  to  Grid2.RowCount  -1  do 
Grid2.CeUs[2,R]:=SquadronName.Text; 


end; 

Notebooklni.Free; 

Notebook.Pagelndex  :=1; 

end; 

end; 

{Update  Safety  Center  PHone  Report} 

procedure  TNoteBookForm.UpdateSafetyCallClick(Sender:  TObject); 
var 

Temp:  string; 

Report:TStringList; 

i,j:integer; 

begin 

Report :  =T  StringList .  Create; 
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With  Report  do  begin 

Add('CALL:  NAVAL  SAFETY  CENTER  ') 

Add("); 

Add('  AUTOVON:  564-2929/3520'); 

Add('  COMMERCIAL:  (804)444-2929/3250  (CALL  COLLECT)') 

Add("); 

Add('INCLUDE  THE  FOLLOWING  INFORMATION  ’) 

Add("); 

Add('A: '+  SquadronName.Text); 

AddCB:  '+  AircraftTypeComboBox.Text); 

Temp:-'; 

for  i:=  ACGrid.RowCount  downto  1  do 
Temp:=  Temp+  ACGrid.Cells[l,i]+' '; 

Add('C:  '+temp); 

Add('D: '+  MishapLocation.Text  +  '  The  Lat/Long  of  the  mishap  is  '+  LatLong.Text); 
AddCE: '+ MishapDescriptionMemo.Text); 

Add(T: '+  'Dammage/Injury  and  Fatalities'); 

Add('G: '+  Gridl.Cells[0,6]+  ':  •  +  Grid  l.Cells[  1,6]); 

Add('  COM: '  +Gridl.Cells[3,6]+'  AV:  ’  +  Gridl  CeM4  61 ) 

Add("); 

end; 

CheckBox8 .  Checked:=True; 

SCVoice.LInes:=  Report; 

Report.Free; 

end; 

(Update  Mishap  Report} 

procedure  TNoteBookForm.UpdateMRClick(Sender:  TObject); 
var 

Temp:  string; 

Report,TempList:TStringList; 

i,j,r,c:  Integer; 

begin 

CheckBoxl  1  .Checked:=True; 

Report :  =T  S  tringLi  st .  Create; 

MishapReport. Lines.  Clear; 

With  Report  do  begin 

Add('PAAUZYUW  JulianDate  -UUUU--  .'); 

Add('ZNR  UUUUU); 

Add('P '+  DateAndTime.Text+'  YZB') 

Add("); 

Add('FM  '+UnitPlad.  T ext); 

Add('TO  CNO  WASHINGTON  DC//JJJ//1); 
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Add('CMC  WASHINGTON  DC//A/SD//’); 

Add('COMNAV  S  AFECEN  NORFOLK  VA//00/10/1 1/FILE//'); 
Add(CadPlad.Text); 

Add('INFO  '); 

Add(NAVAIRWARCENACDIV  LAKEHURST  NJ//JJJ//'); 

Add('COMNAV  SEAS  YSCOM  WASHINGTON  DC//JJJ//'); 

Add(  ShipPtad.  Text); 
if  DoDDead.Itemlndex  =  0  then 

Add(' ARMED  FORCES  INSTITUE  OF  PATHOLOGY  WASHINGTON 
DC//CME-0//*); 

if  CivDead.Itemlndex  =  0  then  Add(*NAVY  JAG  ALEXANDRIA  VA  //JJJ//’); 
if  CarLandBoxChecked  then  Add('LSO  SCHOOL  NAS  OCEANA  VA  //JJJ//’); 
if  ALSSBox.Checked  then  begin 
Add('NAVAIRWARCENWPNDIV  CHINA  LAKE  CA//JJJ//’); 
AddCNAVAIRWARCENACDIV  WARMINSTER  PA//JJJ//’); 

Add(’ALL  AEROMEDICAL  ACTiyiTIES//’); 
end; 


if  HeloLandBox.Checked  then  begin 
AddCHELSUPPRON  EIGHT//*); 
Add(HELSUPPRON  THREE//1); 
end; 


if  SARCheckBox.Checked  then  Add(’HELANTISUBRON  ONE//60//’); 

AddCBT’); 

Add(TJNCLAS  FOUO  //N03750//'); 

Add("); 

Add('SUBJ/THIS  IS  AN  INITIAL  GENERAL  USE  NAVAL  AIRCRAFT  MISHAP 
REPORT/1); 

Add(SquadronName.Text+',  '+MisHapSeverity.Text+ '  '+MishapCategory.Text+ ' ' 

+  'O'  +  IntToStr(MishapNumber.Value)+ '-' 

+  AnsiUpperCase(FonnatDateTinie('yy  ',StrToDateTime(LTime.Text))) 

+',  '+  ACGrid.Cells[0,l]  +  ',/REPORT  SYMBOL  OPNAV  3750-20//'); 

Add('REF/A/DOC/OPNAVINST  3750.6Q/-//'); 

AddCREF/B/DOC/J  AGIN  ST  5800.7C/-//'); 

AddCRMKS/l.  SUMMARY.  '+ MishapDescriptionMemo.Text); 

Add('2  DATA.'); 

Add('  A.  AIRCRAFT.'); 
for  i:=  1  to  ACGrid.RowCount  -1  do  begin 
Add(' '); 
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for  j: —  0  to  ACGrid.ColCount  -  1  do 
Add(  '('+IntToStr(j+l )+') '  +  ACGrid.Cells[j,i]); 
end; 

Add("); 

Add('B  EQUIPMENT.  NA'); 

Add("); 

Add('C.  ENVIRONMENT.'); 

Add('(  1  y+FormatDateTimeChhnn',  StrT  oDateTime(LTime.  Text))); 
Add('(2)'+FormatDateTime('ddmmyy',StrToDateTime(LTime.Text))); 
Add('(3)'+IntToStr(ZuluTimeSet.  Value)); 

Temp.-"; 

if  DayNiteSel.Itemlndex  =  0  then  Temp:=  'DAY'  else  Temp-NIGHT'; 


Add('(4)'+  Temp); 

Add('(5)'+LatLong.  T  ext); 

Add('(6)'+ Altitude.  Text); 

Add('(  7)'+Weather .  T  ext); 

Add("); 

Add('3.  CIRCUMSTANCES'); 

Add('(  A)'+Origin.  T  ext); 

Add('(B)'+MissionCode.  Text); 

Add('(C)'+FPC .  T  ext); 

Add('(D)'+FlightPlan.  T  ext); 

Add('(E)'+Destination.  T  ext); 

Add('(F)'+ AirEvol.  T  ext); 

Add("); 

Add('4.  MISHAP  CATEGORY'); 

Add(MishapSeverity.Text+ '  '+MishapCategory.Text+  ' ' 

+  'O'  +  IntToStr(MishapNumber.Value)+ '-' 

+  AnsiUpperCase(FormatDateTime('yy  ',StrToDateTime(LTime.Text)))); 
Add("); 

Add('5.  DAMAGE  AND  COSTS'); 

Add("); 

If  Damage.  Itemlndex=  0  then 

Add('  A.  AIRCRAFT  DESTROYED')  else  Add(’  A.  TBD’) 

Add('  B.  TBD'); 

Add('  C.  TBD'); 

Add("); 

Add('6.  PERSONNEL  INFORMATION  AND  INJURIES’); 

Add('  A.  SOULS  ON  BOARD:  '+  IntToStr(NumberCrew.  Value  + 
PaxNumber.  Value)); 

Add('  B.  CREW:  '+IntToStr(NumberCrew.  Value)); 
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T  empList : =T  StringList .  Create; 

TempList:=AddGridList(PersGrid); 

AddStrings(T  empList); 

TEmpList.Free; 

AddO; 

if  PaxNumber.  Value  =  0  then  begin 
Add('C.  TOTAL  NUMBER  OF  PASSENGERS:  NA'); 

Add('(l)  INJURED  PASSENGERS:  NA'); 

Add('(2)  UNINJURED  PASSENGERS:  NA); 
end  else 
begin 

Add('C.  TOTAL  NUMBER  OF  PASSENGERS.  '+ 
IntToStr(PaxNumber.  Value)); 

if  InjuredPax.  Value  >  0  then 
begin 

Add('(l)  INJURED  PASSENGERS:  '+IntToStr(InjuredPax.  Value)); 
TempList:=TStringList.Create; 

TempList:=AddGridList(PaxGrid); 

AddStrings(T  empList); 

TempList.Free; 

end 

else  Add('  (1)  INJURED  PASSENGERS:  NA'); 

Report. Add('(2)  UNINJURED  PASSENGERS:  '+ 
IntToStr(PaxNumber.  Value  -  InjuredPax.  Value)); 
end; 


Add(D.  INJURED  NON-OCCUPANTS:  '+IntToStr(InjuredNonOccupants.  Value)); 
Add("); 

AddCE.  AEROMEDICAL  ANALYSIS  WILL  BE  SENT'); 

Add("); 

Add('7.  MISHAP  INVESTIGATION1); 

Add("); 

Add('8.  JAG  MANUAL  INVESTIGATION*); 

AddO; 

Add('  THIS  MISHAP  (DOES/DOES  NOT)  MEET  THE  REQUIREMENTS  IN  REF 
B  FOR  A  JAG  MANUAL  INVESTIGATION1); 

Add('9.  POINTS  OF  CONTACT'); 

AddO; 

T  empList:=TStringList.  Create; 

TempList:=AddGridList(Grid2); 

AddStrings(T  empList); 
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TEmpList.Free; 

Addf//'), 

Add('BT'); 

Add('#0001'); 

end; 

MishapReport.Lines~  Report; 

Report.Free; 

end, 

procedure  TNoteBookForm.UpdateTimeClick(Sender:  TObject); 
var 

LocalTimeStamp,  ZuluTimeStamp:  TDateTime; 
begin 

{Update  Mishap  Info  Time  Groups) 

LocalTimeStamp:=Now; 

ZuluTimeStamp:=(LocalTimeStamp  -  ZuluTimeSet.  Value/24); 
LTime.Text:=DateTimeToStr(LocalTimeStamp), 

ZTime.  T  ext :  =DateTimeT  o  Str(ZuluTimeStamp); 
LocalTime.Text:=FormatDateTime('dd  mmm  yy  hhnn',LocalTimeStamp); 
ZuluTime.Text:=FormatDateTime('dd  mmm  yy  hhnn',ZuluTimeStamp); 
DateAndTime.Text:=  FormatDateTime('ddhhnnZmmmyy',ZuluTimeStamp); 
end; 

procedure  TNoteBookForm.UpdateMishapClick(Sender:  TObject); 
var 

i,j,R:  integer, 
begin 

{Fill  Grids  with  test  data) 
for  R:=  1  to  PersGrid.RowCount-1  do  begin 
PersGrid.Cells[0,R]:=?AC'; 
if  ServiceSel.Itemlndex  =  1  then  begin 
PersGrid.  Cells[l,R]:=  'Capt'; 

PersGrid.Cells[2,R]:=  MOS'; 

PersGrid.Cells[3,R]:=  'USMC'; 
end  else  begin 
PersGrid.Cells[l,R]:='LT'; 

PersGrid.  Cells[2,R]  :='  1 3 1  O'; 

PersGrid.  Cells[3  ,R]  :=,U  SN1; 
end; 

PersGrid.  Cells[4,R]  :=SquadronName.  T  ext; 
PersGrid.Cells[5,R]:='ONDUTY’; 

PersGrid.CeUs[6,R]:='NOINJURY,; 

PersGrid.  Cells[7,R]  :='#OFHOSP 
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PersGrid.Cells[8,R]:='N0LWD'; 

PersGrid.Cells[9,R]:=,NVGS  NOT  USED'; 

PersGrid.CeUs[  1 0,R] OHOURS'; 

PersGrid.Cells[l  1,R]:='OHOURS'; 
end; 
end; 

procedure  TNoteBookForm.AircraftNumberChange(Sender:  TObject); 
begin 

ACGrid.RowCount:=AircraftNumber.  Value  +  1; 
ACGrid.ClientHeight:=Notebookl. Height  -  50; 
end; 

procedure  TNoteBookForm.NumberCrewChange(Sender:  TObject); 
begin 

if  (NumberCrew.  Value  <=2)  then  begin 
PersGrid.Height:=  57; 

PersGrid.RowCount:=2; 

end; 

PersGrid.RowCount:=  NumberCrew.  Value  +1; 
PersGrid.ClientHeight:=Notebookl  Height  -75; 
end; 

procedure  TNoteBookForm. About  lClick( Sender:  TObject); 
var 

About:  TAboutMishap; 
begin 

About:=TAboutMishap.Create(NoteBookForm); 

About.  ShowModal; 

About.Free 

end; 

procedure  TNoteBookForm.InjuredPaxChange(Sender:  TObject); 
begin 

if  PaxNumber.  Value  <  InjuredPax.  Value  then 
PaxNumber.  Value:=  PaxNumber.  Value  +  1; 
if  (InjuredPax.  Value  <=  1)  then  begin 
PaxGrid.Height:=  57; 

PaxGrid.RowCount:=2; 
end  else 

PaxGrid.RowCount:=InjuredPax.  Value  +  1; 

PaxGrid.ClientHeight:=  Notebookl  Height  -  75; 
end; 
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procedure  TNoteBookForm.UpdateMisAircraftClick(Sender:  TObject); 
var 

i,j,k:  integer; 
begin 

{Fill  Aicraft  Grid  with  default  values) 
for  i  :=  1  to  ACGrid.RowCount  -  1  do 
for  j:=0  to  ACGnd. ColCount  -1  do  begin 
ACGrid.Cells[0,i]  :=  AircraftTypeComboBox.  Text; 
ACGrid.Cellstkij-’BUNO'; 

ACGrid.  Cells[2,i]  :=' SIDE#'; 

ACGrid.Cells[3,i]:=  SquadronName.Text; 

ACGrid.Cells[4,i]:-TBD'; 

ACGrid.  Cells[5,i]:='TBD'; 
end; 
end; 

procedure  TNoteBookForm.  Contents  lClick(Sender:  TObject); 
begin 

Application.HelpFile:=('notebook.hlp'); 

Application.HelpContext(  1 000); 
end; 

procedure  TNoteBookForm.MishapReportlClick(Sender:  TObject); 
begin 

Savet)ialog.Filename:-misreprt.txt'; 

SaveDialog.Execute; 

MishapReport.Lines.  SaveToFile(SaveDialog.  Filename); 
end; 

procedure  TNoteBookForm.  SafetyCenterVoiceReport  1  Click(Sender.  TObject); 
begin 

SaveDialog.FileName:- centrvoc.txt'; 

SaveDialog.Execute; 

SCVoice.Lines.SaveToFile(SaveDialog.Filename); 

end; 

procedure  TNoteBookForm.  SaveOprepVoiceReportlClick(Sender:  TObject); 
begin 

SaveDialog.Filename:— Oprepvoc.txt'; 

SaveDialog.Execute; 
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MishapReport.Lines.SaveToFile(SaveDialog.Filename); 

end; 

procedure  TNoteBookForm.OPREPMessagelClick( Sender:  TObject); 
begin 

SaveDialog.Filename:- OPREPmsg.txt’; 

SaveDialog.Execute; 

MsgMemo.Lines.SaveToFile(SaveDialog.Filename); 

end; 

procedure  TNoteBookForm.Button2Click(Sender:  TObject); 
var 

R:  integer; 
begin 

if  PaxNumber.  Value  <  InjuredPax.  Value  then 
PaxNumber.Value:=  InjuredPax.  Value; 

for  R:=  1  to  PAXGrid.RowCount-1  do  begin 
if  ServiceSel.Itemlndex  =  0  then  begin 
PaxGrid.  Cells[0,R]  :=RANK'; 

PaxGrid.Cells[  1  ,R]  :=T>ESG.'; 

PaxGrid.Cells[2,R]:-USN'; 
end  else  begin 

PaxGrid.  Cells[0,R]  —RANK'; 

PaxGrid.  Cells[  1  ,R]  :=lMOS'; 

PaxGrid .  Cells[2,R]  :=’USMC’; 
end; 

PaxGrid.Cells[3rR]:=T)OD'; 

PaxGrid.  Cells[4^.]  :='TBD'; 

PaxGrid.CellstSjRj^'ONDUTY1; 

PaxGrid.Cells[6,R]:='TBD'; 

PaxGrid.Cells[7,R]:-TBD'; 

PaxGrid.  Cells[8,R] :  -  TBD'; 

PaxGrid.  Cells[9,R] : ='TBD'; 
end; 
end; 

procedure  TNoteBookForm.AircraftTypeComboBoxChange(Sender:  TObject); 
begin 

C  ADPlad.  ItemIndex:=AircraftT  ypeComboBox.  Itemlndex; 
end; 
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procedure  TNoteBookForm.OprepVoiceReportlClick(Sender:  TObject); 
begin 

PrintReport(OprepMemo); 

end; 

procedure  TNoteBookForm.OPREPMessage2Click(Sender:  TObject); 
begin 

PrintReport(MsgMemo); 

end; 

procedure  TNoteBookForm.SafetyCenterVoiceReport2Click(Sender:  TObject); 
begin 

PrintReport(  SC  V  oice); 
end; 

procedure  TNoteBookForm.MishapReport2Click(Sender:  TObject); 
begin 

PrintReport(MishapReport) ; 
end; 

procedure  TNoteBookForm.TabContinueClick(Sender:  TObject); 
begin 

With  Notebook  do 
Pagelndex— Pagelndex  +  1; 
end; 

procedure  TNoteBookForm.InfoCompClick(Sender:  TObject); 
begin 

NoteBookl  .Pagelndex.—  NoteBook.Pagelndex  +  1 ; 

TabSetl  .TabIndex:=TabSetl  .Tablndex+l; 
end; 

procedure  TNoteBookForm.MishapInfoCompleteClick(Sender:  TObject); 
begin 

if  MessageDlg('MISHAP  INFORMATION  COMPLETE!  The  next  step  in  the'+ 

'  check  list  is  to  CREATE  THE  OPREP-3  MESSAGE.'+ 

'  Do  you  want  to  continue  with  the  Checklist?', 
mtConfirmation,mbOKCancel,0)  =  mrOk 
then  begin 

CheckBoxl2.Checked:=True; 

NoteBook.Pagelndex—  6; 

end; 

end; 
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procedure  TNoteBookForm.CompeteNextClick(Sender:  TObject); 
begin 

if  MessageDlg('OPREP-3  VOICE  REPORT  COMPLETE!  The  next  step  in  the'+ 

’  check  list  is  FILL  OUT  THE  REMAINING  SUB  TABS  OF  THE  MISHAP  INFO  tab'+ 
'Do  you  want  to  continue  with  the  Checklist?', 
mtConfirmation,mbOKCancel,0)  =  mrOk 
then  begin 

CheckBox7.Checked:=  True; 

NoteBook.PageIndex:=2; 

NoteBook  1  Pagelndex: = 1 ; 

end; 

end; 

procedure  TNoteBookForm.Button7Click(Sender:  TObject); 
begin 

ifMessageDlg('You  have  just  completed  the  OPREP  MESSAGE.  The  next  step  is '+ 

'  is  to  create  THE  SAFETY  CENTER  VOICE  REPORT.'  + 

'  Do  want  to  Continue?', 
mtConfirmation,mbOKCancel,0)  =  mrOk 
then  begin 

CheckBox6.Checked:=  True; 

T  abContinue .  Click; 

end; 

end; 

procedure  TNoteBookForm.YeslClick(Sender:  TObject); 
begin 

if  (MisSevQl.Itemlndex  =  0)  then  MishapCategory.ItemIndex:=  4; 

if  (MisSevQl.Itemlndex  =  1)  and  (MisSevQ2.ItemIndex  =  0)  and 
(MisSevQ3.ItemIndex  =  0)  and  (MisSevQ4.ItemIndex  =  0)  and 
(MisSevQ5.ItemIndex  =  0)  then  MishapCategory.ItemIndex:=  3; 

if  (MisSevQl.Itemlndex  =  1)  and  (MisSevQ2.ItemIndex  =  0)  and 
((MisSevQ3.ItemIndex  =  1)  or  (MisSevQ4.ItemIndex  =  1)  or 
(MisSevQ5.ItemIndex  =  1))  then  MishapCategoiy.ItemIndex:=  2; 

if  (MisSevQl  .Itemlndex  =  1)  and  (MisSevQ2.ItemIndex  =  1)  and 
(MisSevQ3  Itemlndex  =  0)  and  ((MisSevQ4.ItemIndex  =  1)  or 
(MisSevQ5.ItemIndex  =  1))  then  MishapCategory.ItemIndex:=  1; 

if  (MisSevQl.Itemlndex  =  1)  and  (MisSevQ2.ItemIndex  =  1)  and 
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(MisSevQ3.ItemIndex  =1)  then  MishapCategory.ItemIndex:=  0; 

if  (MisSevQl.Itemlndex  =  1)  and  (MisSevQ2.ItemIndex  =  1)  and 
(MisSevQ3.ItemIndex  =  0)  and  (MisSevQ4.ItemIndex  =  0)  and 
(MisSevQ5.ItemIndex  =  0)  then  MishapCategory.ItemIndex:=  3; 
end; 

procedure  TNoteBoolcForm.Button6Click(Sender:  TObject); 
begin 

if  MessageDlg('OFFICER  RECALL  COMPLETE!  The  next  step  in  the'+ 

'  check  list  is  to  fill  out  PAGE  ONE  of  the  Mishap  Info.  Tab'  + 

'  Do  you  want  to  continue  with  the  Checklist?', 
mtConfirmation,mbOKCancel,0)  =  mrOk 
then  begin 

CheckBox5.Checked:=True; 

T  abContinue.  Click; 

end; 

end; 

procedure  TNoteBookForm.GotoMishapCatClick(Sender:  TObject); 
begin 

if  MessageDlg('P  AGE  ONE  of  Mishap  Info.  COMPLETE!  The  next  step  in  the'+ 
'  check  list  is  to  determine  Mishap  Category.'  + 

'  Do  you  want  to  continue  with  the  Checklist?', 
mtConfirmation,mbOKCancel,0)  =  mrOk 
then  begin 

CheckBox9.Checked:=  True; 

TabContinue.Click; 

end; 

end; 

procedure  TNoteBookForm.CompleteMishapCatClick(Sender:  TObject); 
begin 

if  MessageDlgCMISHAP  CATEGORY  COMPLETE!  The  next  step  in  the'+ 

'  check  list  is  to  determine  Mishap  Severtiy.'  + 

'  Do  you  want  to  continue  with  the  Checklist?', 
mtConfirmation,mbOKCancel,0)  =  mrOk 
then  begin 

CheckBox3. Checked—  True; 

T  abContinue.  Click; 

end; 
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end; 


procedure  TNoteBookForm.MishapSevDoneClick(Sender:  TObject); 
begin 

if  MessageDlg('MISHAP  SEVERITY  COMPLETE!  The  next  step  in  the'+ 

1  check  list  is  to  CREATE  THE  OPREP-3  VOICE  REPORTS 
'  Do  you  want  to  continue  with  the  Checklist?', 
mtConfirmation,mbOKCancel,0)  =  mrOk 
then  begin 

CheckBox4 .  Checked  -  True; 

T  abContinue.  Click; 

end; 

end; 

procedure  TNoteBookForm.Button8Click(Sender:  TObject); 
begin 

if  MessageDlgC SAFETY  CENTER  VOICE  REPORT  COMPLETE!  The  next  step  in  the 
'+ 

'  checklist  is  to  complete  the  MISHAP  REPORT.M- 
'  Do  want  to  Continue?', 

mtConfirmation,mbOKCancel,0)  =  mrOk  then  begin 

CheckBox8.  Checked”  True; 

T  abContinue.  Click; 

end; 

end; 

procedure  TNoteBookForm.MRCompleteClick(Sender:  TObject); 
begin 

if  MessageDlgCMISHAP  REPORT  COMLETE!  You  have  finished  all  of  the  required'+ 

'  steps  in  the  checklist.  Make  sure  you  have  saved  and  printed  all'  + 

'  applicable  reports.  Prssing  OK  will  take  you  back  to  the  CheckList  Tab', 
mtConfirmation,mbOKCancel,0)  =  mrOk  then 

begin 

CheckBoxl  1  Checked:=True; 

NoteBook.PageIndex:=0; 

end; 

end; 

procedure  TNoteBookForm.OfficerRecalllClick(Sender:  TObject); 
begin 

PrintGrid(Grid  1 ,','); 
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PrintGrid(Grid2,V); 

end; 

end. 
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APPENDIX  C 


PROLOG  CODE 


A.  PROLOG  FACTS 

/‘File  facts.pl 

Created  by  Hemant  Bhargava  and  Charles  Emde  on  May  8, 1995. 
Following  our  extensive  discussions  on  how  to  formalize  and 
document 

the  mishap  investigation  process. 

7 

/*  This  file  contains  the  database  of  information  inputted  by  the 
user  in  the  form  of  causes  and  supporting  evidence.  The  evidence 
is  textual  for  clarity.  The  actual  implementation  should  contain 
database  field  pointers  rather  than  the  text  descriptions  here.7 
/*  Description  of  Predicates  Used:7 

/* 

probable  cause  predicate  (prob_cause(arg1  ,ang2))  is  read  as 
"the  probable  cause  of  event(arg1)  is  event(arg2). 

evidence  predicate  (evidence(prob_cause1  ,prob_cause2, supporting 
evidence  1)) 

is  read  as  "supporting  evidencel  implies  that  prob_cause2  is  a 
result  of  prob_cause1 . 

7 

/‘Example:  This  mishap  is  fictional.  It  is  the  hypothetical 
example  taken  from  OPNAVINST  3750.6Q,  Appendix  M.  The  scenario 
is  described  as  a  gear  up  landing.  Please  refer  to  the 
instruction  for  details. 

7 

/‘root  mishap*/ 

prob_cause(aircraft_mishap,gear_not_down). 

evidence(aircraft_mishap,gear_not_down,wreckage_inspection). 

/‘one  chain  of  events*/ 

prob_cause(gear_not_down,pilot_overiooked_indicators). 
prob_cause(pilot_overlooked_indicators, fatigue). 
prob_cause(fatigue,four_hours_sleep). 
prob_cause(four_hours_sleep, overwork). 
prob_cause(overwork,poor_supervision). 
evidence(gear_not_down,pilot_overiooked_indicators, interview). 
evidence(fatigue,four_hours_sleep, interview). 
evidence(four_hours_sleep,overwork, interview). 

/*there  is  no  evidence  to  suggest  poor  supervision*/ 
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/*a  second  chain  of  events  based  on  the  pilot  overlooking  the 
indicators*/ 

prob_cause(pilot_overlooked_indicators, distracted). 
prob_cause(pilot_distracted,father_died). 
evidence(pilot_overlooked_indicators,  distracted,  interview). 

/*There  is  no  evidence  that  the  distraction  was  caused  by  the 
father's  death.*/ 

/* a  third  chain  of  events*/ 

prob_cause(gear_not_down,handle_malfunctioned). 

prob_cause(handle_malfunctioned,improper_maintenance). 

prob_cause(improper_maintenance,omitted_step). 

prob_cause(omitted_step,poorly_written_handbook). 

prob_cause(poorly_written_handbook,missing_page). 

evidence(gear_not_down,handle_malfunctioned,wreckage_inspection). 

evidence(handle_malfunctioned,improper_maintenance,records_insp). 

evidence(improper_maintenance,omitted_step, handbook). 

evidence(omitted_step,poorly_written_handbook,expert_interview). 

/* a  fourth  chain  of  events*/ 

prob_cause(gear_not_down,backup_not_used). 

prob_cause(backup_not_used,poor_training). 

prob_cause(poor_training,crew_uncoordinated). 

prob_cause(crew_uncoordinated,no_coord_training). 

prob_cause(no_coord_training,no_command_support). 

evidence(gear_not_down,backup_not_used,wreckage_examination). 

evidence(backup_not_used,poor_training,training_reconds). 

evidence(poor_training,crew_uncoordinated, interview). 

evidence(crew_uncoordinated,no_coord_training,training_records). 

/*a  fifth  chain  of  events*/ 

prob_cause(gear_not_down,no_waming_hom). 

prob_cause(no_waming_hom,malfunctioning_switch). 

prob_cause(malfunctioning_switch, corrosion). 

prob_cause(corrosion,improper_hangering). 

prob_ca  use(improper_ha  ngeri  ng ,  poor_su  pervision) . 

evidence(gear_not_down,no_waming_hom,wreckage_examination). 

evidence(no_waming_hom,malfunctioning_switch,wreckage_examination). 

evidence(malfunctioning_switch, corrosion, wreckage_examination). 

evidence(corrosion,improper_hangering). 

B.  PROLOG  RULES 

/*  File  rules.pl 

Created  by  Hemant  Bhargava  and  Charles  Emde  on  May  8, 1995. 
Following  our  extensive  discussions  on  how  to  formalize  and  document 
the  mishap  investigation  process. 

*/ 
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/‘rules:  first  rule  states  that  a  scenario  consists  of  scenarios  of  at 
least  two  probable  causes,  and  scenarios  and  events  are  transitive.  / 

scenario(X,  Y) 
prob_cause(X,Y). 

scenario(X,  Y) 
prob_cause(X,Z), 
scenario(Z,Y). 


/*  A  scenario  chain  is  constructed  by  following  ALL  the  events  that 
are  (transitively)  probable  causes  for  the  event  (X)  in  question. 

There  may  be  multiple  answers  since  an  event  may  have  more  than 
one  probable  cause.  There  are  two  ways  to  do  this:  □ 
using  recursion  and  using  iteration  (or  accumulators). 

7 

/*  The  recursion  solution  shown  below  is  elegant.  However  the  problem  is 
that  it  will  create  multiple  answers  including  subsets  of  the  correct  chain. 

scenario_chain(Event,  [Head|Rest])  :- 
prob_cause(Event,Head), 
scenario_chain(Head,Rest). 
scenario_chain(_,[]). 

7 

/*  The  iterative  solution  produces  the  same  results,  but  does  so 
in  a  constructive  "forward  chaining"  approach,  which  consumes  less 
memory.  The  second  argument  is  the  accumulator.  At  the  end  the 
accumulator  has  the  answer:  see  the  final  clause. 

It  is  the  final  cause  that  prevents  the  multiple/subset 
answers  from  appearing  as  you  ask  for  more  solutions.  7 

scenario_chain(Event,  Chain)  :- 
scenario_chain_it(Event,  Q,  Chain). 

t*  At  the  start  you  have  accumulated  nothing.  7 

scenario_chain_it(Event,  Temp,  Chain)  :- 
prob_cause(Event,  Cause),  /*  Now  you  add  the  first  cause  7 
append(Temp,  [Cause],  Tempi),  /*  to  your  accumulator  Tempi  7 
scenario_chain_it(Cause,  Tempi,  Chain). 


scenario_chain_it(Event,  Chain,  Answer)  :- 
(prob_cause(Event,  _), !,  fail; 

Answer  =  Chain). 

/*  When  you  reach  an  event  which  has  no  probable  cause, 

you  have  accumulated  in  Chain  the  Answer  for  the  original  event.  7 
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/*The  following  allows  the  user  view  the  results  of  his  deliberation  and 
returns  the  set  of  scenario  explanations  that  are  chained  together  and 
are  supported  by  evidence*/ 


explain_scenario(X,Y, Explanation) 
prob_cause(X,Y), 
evidence  (X,Y,EV), 

Explanation  =  [X,'was  caused  by', Y, 'and  is  supported  by', EV, 

explain_scenario(X,Y, Explanation) not(prob_cause(X,Y)), 
prob_cause(X,Z), 
explain_scenario(X,Z,ExpX2), 
scenario(Z,Y), 

explain_scenario(Z,Y,ExpZY), 
append(ExpXZ,ExpZY,  Explanation). 

C.  EXAMPLE  SCRIPTS 
1.  prob_cause(X,Y). 

prob_cause(X,Y). 

X  =  aircraft_mishap 

Y  =  gear_not_down  ; 

X  =  gear_not_down 

Y  =  pilot_overiooked_indicators ; 

X  =  pilot_overlooked_indicators 

Y  =  fatigue ; 

X  =  fatigue 

Y  =  four_hours_sleep ; 

X  =  four_hours_sleep 

Y  =  overwork ; 

X  =  overwork 

Y  =  poor_supervision  ; 

X  =  pilot_overlooked_indicators 
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Y  =  distracted  ; 


X  =  pilot_distracted 

Y  =  father_died  ; 

X  =  gear_not_down 

Y  =  handle_malfunctioned ; 

X  =  handlejnalfunctioned 

Y  =  improperjnaintenance ; 

X  =  improper_maintenance 

Y  =  omitted_step ; 

X  =  omitted_step 

Y  =  pooriy_written_handbook 

X  =  poorly_written_handbook 

Y  =  missing_page  ; 

X  =  gear_not_down 

Y  =  backup_not_used ; 

X  =  backup_not_used 

Y  =  poorjraining ; 

X  =  poorjraining 

Y  =  crew_uncoordinated  ; 

X  =  crewjincoordinated 

Y  =  no_coordJraining ; 

X  =  no_coord Jraining 

Y  =  no_command_support ; 


X  =  gear_not_down 

Y  =  no_waming_hom  ; 

X  =  no_waming_hom 

Y  =  malfunctioning_switch  ; 

X  =  malfunctioning_switch 

Y  =  corrosion  ; 

X  =  corrosion 

Y  =  improperjiangering  ; 

X  =  improperjiangering 

Y  =  poor_supervision ; 

No 

2.  scenario_chain(X,Y). 

scenario_chain(X,Y). 

X  =  aircraft_mishap 

Y  =  [gear_not_down,pilot_overlookedjndicators, fatigue, 
four_hours_sleep, overwork, poor_supervision] ; 

X  =  aircraft_mishap 

Y  =  [gear_not_down,pilot_overlookedJndicators, distracted] ; 

X  =  aircraft_mishap 

Y  =  [gear_not_down,handle_malfunctioned,improper_maintenance, 
omitted_step,poof1y_writtenJiandbook,missing_page] ; 

X  =  aircraft_mishap 

Y  =  [gear_not_down,backup_not_used,poorjraining,crew_uncoordinated, 
no_coordjraining,no_command_support] ; 

X  =  aircraft_mishap 
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Y  =  [gear_not_down,no_waming_hom,malfunctioning_switch, corrosion, 
improper_hangering,poor_supervision] ; 

X  =  gear_not_down 

Y  =  [pilot_overlooked_indicators,  fatigue,  four_hours_sleep, 
overwork, poor_supervision] ; 

X  =  gear_not_down 

Y  =  [pilot_overlookedJndicators, distracted] ; 

X  =  pilot_over1ooked_indicators 

Y  =  [fatigue, four_hours_sleep, overwork, poor_supervision] ; 

X  =  fatigue 

Y  =  [four_hours_sleep, overwork, poor_supervision] ; 

X  =  four_hours_sleep 

Y  =  [overwork, poor_supervision] ; 

X  =  overwork 

Y  -  [poor_supervision] ; 

X  =  pilot_overlooked_indicators 

Y  =  [distracted] ; 

X  =  pilot_distracted 

Y  =  [father_died] ; 

X  =  gear_not_down 

Y  =  [handle_malfunctioned,improper_maintenance,omitted_step, 
poorly_written_handbook,missing_page] ; 

X  =  handle_malfunctioned 

Y  =  [improper_maintenance,omitted_step,poorly_written_handbook, 
missing  page] ; 
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X  =  improper_maintenance 

Y  =  [omitted_step,pooriy_written_handbook,missing_page] ; 

X  =  omitted_step 

Y=  [poorly_written_handbook,missing_page] ; 

X  =  poorly_written_handbook 

Y  =  [missing_page] ; 

X  =  gear_not_down 

Y  =  [backup_not_used,poor_training,crew_uncoordinated,no_coord_training, 
no_command_support] ; 

X  =  backup_not_used 

Y  =  [poor_training,crew_uncoordinated,no_coord_training, 
no_com  m  a  nd_su  pport] ; 

X  =  poor_training 

Y  =  [crew_uncoordinated,no_coord_training,no_command_support] ; 

X  =  crew_uncoordinated 

Y  =  [no_coond_training,no_command_support] ; 

X  =  no_coord_training 

Y  =  [no_command_support] ; 

X  =  gear_not_down 

Y  =  [no_waming_hom,malfunctioning_switch, corrosion, improper_hangering, 
poor_supervision] ; 

X  -  no_waming_hom 

Y  =  [malfunctioning_switch, corrosion, improper_hangering,poor_supervision] ; 
X  =  malfunctioning_switch 
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Y  =  [corrosion, improper_hangering,poor_supervision] ; 


X  =  corrosion 

Y  =  [improper_hangering,poor_supervision] ; 

X  =  improper_hangering 

Y  =  [poor_supervision] ; 

No 

D.  INTERFACE  TOOLS 

1.  Query  Generation 
queryexe 

/*  scenario_chain_exe,  */ 
scenario_exe. 

scenario_exe 
/*  repeat,  */ 
show_scenario(X), 
scenario(X,Y), 

write(X),  writeC  caused  by '),  write(Y). 

scenario_exe.  /*  when  there's  no  more  to  go.  *1 

scenario_chain_exe(Event) 
scenario_chain(Event,  Answer), 
write(Answer). 

r 

scenario_chain_exe 

repeat, 

show_scenario(Event),  comes  from  query  file 
scenario_chain(Event,  Answer), 
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write(Answer),  modify  this  to  write  answer  nicely  fail.*/ 
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APPENDIX  D 


MISHAP  EXPERT  VERSION  I.01B  OBJECT  PASCAL  SOURCE  CODE 


A.  MAIN  FORM 

unit  Main; 
interface 

uses 

SysUtils,  WinTypes,  WinProcs,  Messages,  Classes,  Graphics,  Controls, 

Forms,  Dialogs,  StdCtrls,  Buttons,  ExtCtrls,  Menus,  TabNotBk,  Stmgfun,  Allsce, 
Explain,  Misexp,  Unsupp; 

type 

TMainForm  =  class(TForm) 

MainMenu:  TMainMenu; 

FileNewItem:  TMenultem; 

FileOpenltem:  TMenultem; 

FileSaveltem:  TMenultem; 

FiieSaveAsItem:  TMenultem; 

FilePrintltem:  TMenultem; 

FilePrintSetupItem:  TMenultem; 

FileExitltem:  TMenultem; 

EditUndoltem:  TMenultem; 

EditCutltem:  TMenultem; 

EditCopyltem:  TMenultem; 

EditPasteltem:  TMenultem; 

WindowTileltem:  TMenultem; 

WindowCascadeltem:  TMenultem; 

WindowArrangeltem:  TMenultem; 

HelpContentsItem:  TMenultem; 

HelpSearchltem:  TMenultem; 

HelpHowTollseltem:  TMenultem; 

HelpAboutltem:  TMenultem; 

OpenDialog:  TOpenDialog; 

SaveDialog:  TSaveDialog; 

PrintDialog:  TPrintDialog; 

PrintSetupDialog:  TPrinterSetupDialog; 

SpeedBar  TPanel; 

SpeedButtonl :  TSpeedButton;  { &New } 

SpeedButton2:  TSpeedButton;  {  &Open... } 

SpeedButton3:  TSpeedButton;  {  &Save  } 

SpeedButton4:  TSpeedButton;  {  Save  &As... } 

SpeedButton5:  TSpeedButton;  { &Print... } 

SpeedButton6:  TSpeedButton;  {  P&rint  Setup... } 

SpeedButton7:  TSpeedButton;  {  &Undo } 

SpeedButton8:  TSpeedButton;  { Cu&t } 

SpeedButton9:  TSpeedButton;  {  &Copy  } 
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SpeedButtonlO:  TSpeedButton;  {  &Paste  } 
SpeedButtonll:  TSpeedButton; 
TabbedNotebookl :  TTabbedNotebook; 
Panell :  TPanel; 

Labell:  TLabel; 

Label2:  TLabel; 

Panel2:  TPanel; 

Label3:  TLabel; 

Button  1:  TButton; 

Label4:  TLabel; 

Memol :  TMemo; 

Panel3:  TPanel; 

Edit3:  TEdit; 

Memo2:  TMemo; 

Memo3:  TMemo; 

ListBox2:  TListBox; 

Label5:  TLabel; 

Label6:  TLabel; 

Label7:  TLabel; 

Button2:  TButton; 

Panel4:  TPanel; 

Label8:  TLabel; 

ListBox3:  TListBox; 

ListBox4:  TListBox; 

Label9:  TLabel; 

Button3:  TButton; 

Labell  0:  TLabel; 

Labell 2:  TLabel; 

Button4:  TButton; 

Button5:  TButton; 

Editl:  TEdit; 

Edit2:  TEdit; 

LIstBoxI :  TListBox; 

Labell  1:  TLabel; 

Panel5:  TPanel; 

Labell  3:  TLabel; 

ListBox5:  TListBox; 

Panel6:  TPanel; 

Labell 4:  TLabel; 

ListBox6:  TListBox;  {  &Contents } 
procedure  FileNew(Sender:  TObject); 
procedure  FileOpen(Sender:  TObject); 
procedure  FileSave(Sender:  TObject); 
procedure  FileSaveAs(Sender:  TObject); 
procedure  FilePrint(Sender:  TObject); 
procedure  FilePrintSetup(Sender:  TObject); 
procedure  FileExit(Sender:  TObject); 
procedure  EditUndo(Sender:  TObject); 
procedure  EditCut(Sender:  TObject); 
procedure  EditCopy(Sender:  TObject); 
procedure  EditPaste(Sender:  TObject); 
procedure  WindowTile(Sender:  TObject); 
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procedure  WindowCascade(Sender:  TObject); 
procedure  WindowArrange(Sender:  TObject); 
procedure  HelpContents(Sender:  TObject); 
procedure  HelpSearch(Sender:  TObject); 
procedure  HelpHowToUse(Sender:  TObject); 
procedure  HelpAbout(Sender  TObject); 
procedure  Button1Click(Sender  TObject); 
procedure  Edit1Enter(Sender:  TObject); 
procedure  Edit1Exit(Sender:  TObject); 
procedure  Button2Click(Senden  TObject); 
procedure  Edit1KeyDown(Sender:  TObject;  var  Key:  Word; 
Shift:  TShiftState); 

procedure  Edit2KeyDown(Sender:  TObject;  var  Key:  Word; 
Shift:  TShiftState); 

procedure  Edit2Exit(Senden  TObject); 
procedure  Edit3KeyDown(Sender:  TObject;  var  Key:  Word; 
Shift:  TShiftState); 

procedure  Edit3Exit(Sender:  TObject); 
procedure  Button3Click(Sender:  TObject); 
procedure  Button5Click(Sender:  TObject); 
procedure  FormCreate(Sender  TObject); 
end; 

var 

MainForm:  TMainForm; 

Scenario:  TStringList; 

EvList:  TStringList; 

TempList:TStringList; 

ChainList:TStringList; 

Chainlndex:lnteger; 

{TempCauseList:  TStringList;} 


implementation 
{$R  *.DFM} 

procedure  TMainForm.FileNew(Sender:  TObject); 
begin 

{  Add  code  to  create  a  new  file } 
end; 

procedure  TMainForm.FileOpen(Sender:  TObject); 
begin 

if  OpenDialog. Execute  then 
begin 

{ Add  code  to  open  OpenDialog.FileName  } 
end; 
end; 

procedure  TMainForm.FiieSave(Sender  TObject); 
begin 


{ Add  code  to  save  current  file  under  current  name  } 
end; 

procedure  TMainForm.FileSaveAs(Sender:  TObject); 
begin 

if  SaveDialog. Execute  then 
begin 

{ Add  code  to  save  current  file  under  SaveDialog. FileName } 
end; 
end; 

procedure  TMainForm.FilePrint(Sender:  TObject); 
begin 

if  PrintDialog. Execute  then 
begin 

{ Add  code  to  print  current  file } 
end; 
end; 

procedure  TMainForm.FilePrintSetup(Sender:  TObject); 
begin 

PrintSetupDialog.Execute; 

end; 

procedure  TMainForm.FileExit(Sender:  TObject); 
begin 
Close; 
end; 

procedure  TMainForm.EditUndo(Sender:  TObject); 
begin 

{ Add  code  to  perform  Edit  Undo } 
end; 

procedure  TMainForm.EditCut(Sender:  TObject); 
begin 

{ Add  code  to  perform  Edit  Cut } 
end; 

procedure  TMainForm.EditCopy(Sender  TObject); 
begin 

{  Add  code  to  perform  Edit  Copy } 
end; 

procedure  TMainForm.EditPaste(Sender  TObject); 
begin 

{  Add  code  to  perform  Edit  Paste  ) 
end; 

procedure  TMainForm.WindowTile(Sender:  TObject); 
begin 
Tile; 
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end; 

procedure  TMainForm.WindowCascade(Sender:  TObject); 
begin 
Cascade; 
end; 

procedure  TMainForm.WindowArrange(Sender:  TObject); 
begin 

Arrangelcons; 

end; 

procedure  TMainFonm.HelpContents(Sender:  TObject); 
begin 

Application.HelpCommand(HELP_CONTENTS,  0); 
end; 

procedure  TMainForm.HelpSearch(Sender.  TObject); 
const 

EmptyString:  PChar  = "; 
begin 

Application.HelpCommand(HELP_PARTIALKEY,  Longint(EmptyString)); 
end; 

procedure  TMainFonm.HelpHowToUse(Sender:  TObject); 
begin 

Application.HelpCommand(HELP_HELPONHELP,  0); 
end; 

procedure  TMainForm.HelpAbout(Sender:  TObject); 
begin 

{  Add  code  to  show  program's  About  Box } 
end; 

procedure  TMainFonm.Button1Click(Sender:  TObject); 
var 

i,j :  integer; 
begin 

for  i  :=0  to  ListBoxI  .Items.Count  -  2  do 
begin 

Scenario.Add(ProbCause(ListBox1  .Itemsfi],  ListBoxI  ,ltems[i+1  ])); 
ListBox3. Items  :=  Scenario; 

ListBox6.ltems  :=  Scenario; 
end; 
end; 

procedure  TMainForm.Edit1Enter(Sender:  TObject); 
begin 

Scenario:=TStringList.Create; 

EvList:=TStringList.Create; 

{TempCauseList. Create;} 
end; 
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procedure  TMainForm.Edit1Exit(Sender:  TObject); 
begin 

Buttonl. Enabled  :=  True; 

ListBoxI  .ltems.Add(Edit1  .text); 
editl  .enabled  :=  false; 
labell. visible  :=  false; 
end; 

procedure  TMainForm.Button2Click(Sender:  TObject); 
begin 

ListBox2.  Items.  Add(Edit3.T  ext) ; 

ListBox4.  Items.  Add(Ed  it3.T  ext) ; 

Edit3.Clear; 

{EvList.Add(Edit3.Text); 

ListBox2.ltems:=EvList; 

ListBox4.ltems:=EvList; 

Edit3. Clear; 

Edit3.SetFocus;} 

end; 

procedure  TMainForm. Editl  KeyDown(Sender:  TObject;  var  Key:  Word; 
Shift:  TShiftState); 
begin 

if  (key  =  VKJRETURN)  then 
Edit2.SetFocus; 
end; 

procedure  TMainForm. Edit2KeyDown(Sender:  TObject;  var  Key:  Word; 
Shift:  TShiftState); 
begin 

if  (key  =  VKJRETURN)  then 
panell  .setfocus; 
edit2.setfocus; 
end; 

procedure  TMainForm. Edit2Exit(Sender:  TObject); 
begin 

ListBoxI .  Items.  Add(Edit2.Text); 

Editl  .Text:=Edit2.Text; 

Editl  .Enabled:=False; 

Edit2.Clear; 

labell  .visible  :=  false; 
labell  1  .visible  :=  true; 
end; 

procedure  TMainForm.Edit3KeyDown(Sender:  TObject;  var  Key:  Word; 
Shift:  TShiftState); 
begin 

if  (key  =  VKJRETURN)  then 
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Memo2.setFocus; 

end; 

procedure  TMainForm.Edit3Exit(Sender:  TObject); 
begin 

ListBox2.  ltems.Add(Edit3.T  ext); 

ListBox4.  Items.  Add(Edit3  .Text) ; 

Edit3.Clear; 

end; 

procedure  TMainForm.Button3Click(Sender:  TObject); 

var  k,l:integer; 
first,  second:string; 
begin 
try 

first:=ListBox3.ltems[ListBox3.ltemlndex]; 

Delete(first,1,11); 

Delete(first,Length(first)-1 ,2); 

ListBox5.items.AddCevidence(’+first+7+ListBox4.ltems[ListBox4.ltemlndexl+ 

except 

on  E:  EStringListError  do 

MessageDIgCSelect  a  prob_cause  and  evidence!',  mtlnformation, 

[mbOK],  0); 
end; 

end; 

procedure  TMainForm.FormCreate(Sender:  TObject); 
begin 

ChainList:=TstringList.Create; 

TempList:=TStringList.Create; 

Chainlndex  :=  0; 

end; 

procedure  TMainForm.Button5Click(Sender:  TObject); 
begin 

TempList.AddStrings(ListBox5.ltems); 

TempList.Addstrings(ListBox6.ltems); 
ChainList.AddObject(lntToStr(Chainlndex),  TempList); 
Chainlndex:=Chainlndex  +  1 ; 

TempList:=TStringList(ChainList.Objects[0]); 

TempList.SaveToFileCc:\pl\facts.pr); 

BtnRightDIg.Show; 

end; 


end. 
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B.  UNSUPPORTED  SCENARIO  SCREEN 
unit  Unsupp; 

interface 

uses  WinTypes,  WinProcs,  Classes,  Graphics,  Forms,  Controls,  Buttons, 
StdCtrls,  ExtCtris; 

type 

TBtnRightDlg2  =  class(TFomn) 

OKBtn:  TBitBtn; 

CancelBtn:  TBitBtn; 

HelpBtn:  TBitBtn; 

Bevell :  TBevel; 

Panel4:  TPanel; 

Label8:  TLabel; 

ListBox3:  TListBox; 

Labell :  TLabel; 

Memol :  TMemo; 

Button  1:  TButton; 

Button2:  TButton; 

ListBoxI :  TListBox; 

procedure  Button1Click(Sender:  TObject); 
procedure  FormActivate(Sender:  TObject); 
private 

{  Private  declarations  } 
public 

{ Public  declarations } 
end; 

var 

BtnRightDlg2:  TBtnRightDlg2; 

implementation 
uses  Main; 

{$R  *.DFM} 

procedure  TBtnRightDlg2.Button1Click(Sender:  TObject); 
var 

Prolog  :word; 

FileName:  string; 
begin 

Prolog:=WinExecCc:/pl/pl  -f  c:/pl/start.pl',1); 

ListBoxI .  Items.  Load  From  File('c:\pl\Answer.  pi') ; 
end; 

procedure  TBtnRightDlg2.FormActivate(Sender:  TObject); 
begin 

NstBox3.ltems  :=  TempList; 
end; 

end. 
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